Trạng thái gian lận trên L2 của Ethereum

Tôi rất coi trọng điều này. Từ năm sau, tôi sẽ chỉ công khai đề cập đến những dự án L2 đã đạt giai đoạn 1 trở lên trên blog, diễn thuyết, và các sự kiện khác, có thể sẽ có một khoảng thời gian ân xá ngắn hạn đối với một số dự án mới, thú vị.

Dù tôi có đầu tư hay không, hoặc bạn có phải là bạn bè của tôi hay không, thì cũng phải đạt được giai đoạn một, nếu không sẽ không được đề cập.

Hệ thống "giai đoạn" của Rollup là một khung để đánh giá mức độ an toàn một cách sơ bộ từ giai đoạn 0 đến giai đoạn 2. Hiện nay, chỉ có Arbitrum và Optimism trong Rollup phổ biến đạt được giai đoạn 1, hầu hết các Optimistic Rollup khác vẫn ở giai đoạn 0.

Trong tình huống này, đã xuất hiện một số vấn đề:

Kể từ khi Optimistic Rollup được giới thiệu đã được 3 năm, tại sao vẫn chưa có dự án nào đạt được giai đoạn 2 cao nhất?
Khi nào có thể mong đợi Optimistic Rollup đạt giai đoạn 2?

Bài viết này nhằm trả lời những câu hỏi này bằng cách phân tích các bằng chứng gian lận và thách thức của Optimistic Rollup, và khám phá cách mà mỗi dự án nỗ lực để thực hiện giai đoạn 2. Ngoài ra, bài viết còn đưa ra triển vọng phát triển tương lai của Optimistic Rollup và hệ thống bằng chứng gian lận.

1.2. So sánh giữa Optimistic Rollup và ZK Rollup

Như mọi người đều biết, tốc độ của Ethereum chậm và Rửa tiền cao. Các nhà nghiên cứu và nhà phát triển trong cộng đồng Ethereum đã nỗ lực không ngừng để giải quyết vấn đề này. Sau khi khám phá các giải pháp như Phân mảnh (sharding) và plasma, cộng đồng cuối cùng đã xác định Rollup là phương pháp chính để mở rộng quy mô. Do đó, các nền tảng Rollup như Arbitrum, Optimism và zkSync đã nổi lên. Theo dữ liệu từ L2Beat, hiện có khoảng 40 Rollup đang hoạt động, và một số giải pháp khác như Validium và Optimium đang sử dụng alt-DA để đạt được sự mở rộng cao hơn, tổng cộng khoảng 41 nền tảng. Ngoài ra, dự kiến sẽ có khoảng 80 nền tảng Rollup mới được triển khai.

（Tình hình hiện tại của L2 | Nguồn: L2Beat）

Khái niệm cốt lõi của Rollup là thực hiện giao dịch ở off-chain, chỉ gửi dữ liệu giao dịch và trạng thái kết quả đến gốc Ethereum, từ đó thực hiện việc mở rộng. Người dùng có thể gửi tiền vào hợp đồng cầu cụ thể trên Ethereum, chuyển tiền vào Rollup và thực hiện giao dịch bên trong Rollup. Do dữ liệu giao dịch sẽ được gửi đến Ethereum và một khi được xác nhận, nó sẽ không thể thay đổi mà không làm tổn thương tính bảo mật của Ethereum, vì vậy mọi người cho rằng Rollup "kế thừa tính bảo mật của Ethereum".

Nhưng điều này có phải là sự thật không? Nếu người đề xuất xử lý giao dịch bên trong Rollup là người có ý đồ xấu thì sao? Người đề xuất có ý đồ xấu có thể sửa đổi số dư của Alice, chuyển nó vào tài khoản của họ và rút nó ra khỏi Ethereum, từ đó hiệu quả là đánh cắp tiền của Alice.

Để ngăn chặn tình huống này, cần có các cơ chế bảo mật bổ sung khi rút tiền từ Rollup sang ETH. Chỉ khi cung cấp chứng minh cho hợp đồng cầu nối ETH rằng giao dịch rút tiền đã được xử lý đúng và được bao gồm trong chuỗi L2, giao dịch rút tiền mới có thể hoàn thành.

Ý nghĩa của phương pháp đơn giản nhất, cũng là cách mà mỗi Rollup đều áp dụng, là so sánh giá trị hash của giao dịch rút tiền với gốc trạng thái của Rollup, để chứng minh rằng giao dịch rút tiền đã được bao gồm đúng trong trạng thái của Rollup. Điều này đòi hỏi gửi cùng lúc giao dịch rút tiền và gốc trạng thái cho hợp đồng cầu của Ethereum. Người dùng gửi giao dịch rút tiền của họ, trong khi Người xác thực tính toán và gửi gốc trạng thái.

Tuy nhiên, nếu người xác thực của trạng thái gốc được gửi là người có ý đồ xấu và gửi trạng thái gốc sai, có thể đe dọa đến an toàn tài sản của người dùng. Để giảm thiểu rủi ro này, đã đưa ra hai cơ chế chính, dẫn đến sự khác biệt giữa Optimistic Rollup và ZK Rollup.

**ZK tổng hợp **ZK Rollup không chỉ yêu cầu Người xác thực gửi gốc trạng thái mà còn cung cấp một bằng chứng ZK để xác minh tính chính xác của việc tính toán gốc trạng thái. Nếu Người xác thực gửi gốc trạng thái sai, bằng chứng ZK sẽ không thể vượt qua việc xác minh của hợp đồng xác minh L1, ngăn chặn việc gửi gốc trạng thái độc hại.
**Tối ưu Rollup **Optimistic Rollup cho phép các Người xác thực được chỉ định gửi một gốc trạng thái mà không cần bất kỳ bảo đảm bổ sung nào, dựa trên giả định rằng sự gửi đó là trung thực. Tuy nhiên, nếu gốc trạng thái được gửi không chính xác, bất kỳ ai cũng có thể nêu ra khiếu nại và ngăn chặn việc sử dụng gốc trạng thái đó trong quá trình rút tiền. Người nêu khiếu nại phải gửi bằng chứng cho ETH để chứng minh rằng gốc trạng thái có sai sót, điều này được gọi là bằng chứng gian lận (Fraud Proof).

Để đảm bảo việc giải quyết an toàn như L1 审查等攻击的之意, thời gian rút tiền của Optimistic Rollup thường bị trễ khoảng một tuần.

1.3. Tại sao cần bằng chứng gian lận?

Khác với ZK Rollup, người xác thực của Optimistic Rollup có thể gửi trạng thái gốc không chính xác và cố gắng thao túng giao dịch rút tiền. Bằng chứng gian lận hiệu quả ngăn chặn điều này, đảm bảo an toàn vốn trong hợp đồng cầu.

Nếu không có cơ chế bằng chứng gian lận mạnh mẽ, Optimistic Rollup không thể hoàn toàn kế thừa tính bảo mật của Ethereum. Ví dụ, trong hệ thống Arbitrum hiện tại, nếu tất cả các người xác thực có cùng ý đồ, họ có thể đánh cắp tất cả các tài sản trong hợp đồng cầu nối. Tương tự, trên các Rollup dựa trên ngăn xếp OP như Base, do Mạng chính chưa triển khai cơ chế chứng minh lỗi không cần phép, một người xác thực độc hại cũng có thể đánh cắp tài sản.

Do đó, bằng chứng gian lận đóng vai trò quan trọng trong tính bảo mật của Optimistic Rollup, và bất kỳ hệ thống nào thiếu cơ chế bằng chứng gian lận hoàn thiện sẽ đối mặt với rủi ro đối với tài sản của người dùng.

Bài viết này sẽ đánh giá các rủi ro mà các Optimistic Rollup đối mặt và xem xét cơ chế chứng minh gian lận của chúng, cũng như ưu điểm và nhược điểm của chúng.

1.4. Hướng tới giai đoạn 2: "Tháo bánh xe tập"

Hệ thống chứng minh gian lận đã đóng vai trò quan trọng trong quá trình giúp Optimistic Rollup thực hiện giai đoạn 2. Khung giai đoạn được đề xuất bởi Vitalik và hiện đang được L2Beat vận hành để đánh giá mức độ an toàn của Rollup.

Trong hệ sinh thái ETH, giai đoạn khung được so sánh với việc học cách đi xe đạp. Rollup giai đoạn 0 phụ thuộc vào giả định tin tưởng nhiều nhất, tương tự như xe ba bánh có bánh trợ giúp, trong khi Rollup giai đoạn 2 hoàn toàn kế thừa tính an toàn của ETH được so sánh với xe đạp hai bánh đã bỏ bánh trợ giúp.

Dưới đây là các tiêu chuẩn chi tiết từ giai đoạn 0 đến giai đoạn 2:

Như đã đề cập trong văn bản trước, để đạt được giai đoạn 1 hoặc giai đoạn 2 của Optimistic Rollup, việc thực hiện một cơ chế bằng chứng gian lận và thách thức hợp lý là vô cùng quan trọng. Với những tiêu chuẩn này, hệ thống bằng chứng gian lận thỏa mãn yêu cầu giai đoạn 2 nên có các đặc điểm sau:

Hệ thống hoạt động tốt, không có lỗi đã biết và có tính năng "1 trong N".
Đây là một hệ thống không cần phép, bất kỳ ai cũng có thể gửi bằng chứng.
Nếu hệ thống chứng minh có lỗ hổng, nó phải được chứng minh trên chuỗi.

Trong phần sau của bài viết, chúng tôi sẽ thảo luận về cách mà các loại giao thức cố gắng thực hiện những chức năng này.

2. bằng chứng gian lận - Khái niệm và hiểu lầm

2.1. bằng chứng gian lận是如何实施的？

bằng chứng gian lận cung cấp bằng chứng trên chuỗi cho thấy rằng gốc trạng thái đã được gửi không chính xác, có nghĩa là một hàm chuyển đổi trạng thái cụ thể trong L2 đã được thực hiện không đúng cách. Một phương pháp đơn giản là bằng cách bắt đầu từ gốc trạng thái được xác nhận trước đó, tạo ra bằng chứng cho tất cả các khối L2 cho đến gốc trạng thái hiện tại, từ đó chứng minh rằng gốc trạng thái không chính xác. Tuy nhiên, phương pháp này tốn kém và mất thời gian.

因此，生成有效的bằng chứng gian lận时，需要先缩小到特定的不正确状态转换，再为该部分生成证明。大多数bằng chứng gian lậngiao thức都遵循这种方法。

Bằng chứng gian lận和质疑giao thức通常包括以下步骤：

Người xác thực (người đề xuất) thường xuyên gửi kết quả đầu ra (hoặc khai báo) có chứa gốc trạng thái L2 cho ETH.
Nếu Người xác thực (质疑者) không đồng ý với đầu ra này, họ sẽ khởi động đối chất.
Người đề xuất và người nghi ngờ nhận biết các phần khác biệt thông qua quy trình gọi là phân chia hai hoặc phân tích, và làm rõ chúng đến cấp chỉ thị hoặc cấp Khối (ZK Rollup).
Người nghi ngờ sẽ nộp bằng chứng gian lận on-chain để chứng minh phần không chính xác. Thông thường, các giao thức như Arbitrum và Optimism sẽ thực hiện các chỉ thị nghi ngờ on-chain để xác minh.
Nếu bằng chứng gian lận được xác minh, đầu ra không chính xác sẽ bị loại bỏ hoặc thay thế. Theo giao thức tranh chấp, người đề xuất có thể bị phạt, trong khi người tranh chấp sẽ nhận được phần thưởng.

2.2. Các hiểu lầm phổ biến: bằng chứng gian lận và sự nghi ngờ không thể Rollback chuỗi

Cần lưu ý rằng, ngay cả khi có bằng chứng gian lận và tranh cãi, chuỗi cũng sẽ không bị Rollback. Bằng chứng gian lận đảm bảo rằng “tiền trong hợp đồng cầu sẽ không bị rút ra một cách ác ý”, mà không liên quan đến việc Rollback trạng thái không chính xác.

Lý do chính không phải là Rollback là không cần thiết. Khi có sự chuyển đổi trạng thái không đúng trong Rollup, vấn đề cốt lõi là kẻ xấu có thể đánh cắp tiền của người dùng từ cầu. Để ngăn chặn điều này, chỉ cần đảm bảo rằng gốc trạng thái được gửi đến L1 là chính xác. Quá trình này không liên quan đến việc Rollback chuỗi, chỉ cần ngăn chặn xác nhận cuối cùng của gốc trạng thái độc ác, bằng chứng gian lận và cơ chế nghi ngờ là đủ.

Ngoài ra, nếu người đề xuất trạng thái gốc và người sắp xếp khối chuỗi L2 khác nhau, thì cũng không cần thiết phải thực hiện cơ chế Rollback.

Do đó, ngay cả khi các vấn đề được giải quyết thành công, L2 chain cũng sẽ không bị Rollback; chỉ có State Root (output hoặc declaration) được gửi đến L1 sẽ bị xóa hoặc thay thế. Nếu bằng chứng gian lận và cơ chế nghi ngờ hoạt động bình thường, an ninh vốn của người dùng sẽ được đảm bảo.

2.3. Ví dụ thực tế: Sự nghi ngờ của Kroma vào tháng 4 năm 2024

Thông qua các trường hợp tranh chấp thực tế, có thể thấy rằng toàn bộ chuỗi Rollup sẽ không bị Rollback, chỉ có gốc đầu ra được thay thế hoặc xóa bỏ. Đến thời điểm hiện tại, chỉ có một trường hợp tranh chấp thành công được biết đến trên Mạng chính diễn ra vào tháng 4 năm 2024 với Kroma, một hệ thống Rollup kết hợp dựa trên OP Stack, sử dụng chứng minh lỗi ZK.

Kroma là một OP Stack dựa trên Rollup, có hệ thống ZK Proof và hệ thống xác thực không cần phê duyệt riêng của mình. Vào ngày 1 tháng 4 năm 2024, nguồn gốc L1 của bộ sắp xếp Kroma đã gặp vấn đề, dẫn đến việc bộ sắp xếp tạo ra các Khối không chính xác. Ngoài ra, người xác thực đã quan sát được rằng người xác thực đã gửi một đầu ra gốc không chính xác. Ngay sau khi đầu ra gốc được gửi đi, có tổng cộng 12 người nghi ngờ đã nêu ra câu hỏi về đầu ra đó.

Một trong những người nghi ngờ đã thành công trong việc gọi hàm proveFault, xóa đầu ra sai lầm.

Người hỏi đã thực hiện thành công hàm proveFault | Nguồn:etherscan

Đây là trường hợp thử thách đầu tiên thành công trong lịch sử Mạng chính Rollup ETH. Đây cũng là trường hợp đầu tiên sau khoảng ba năm kể từ khi Optimistic Rollup đầu tiên (Arbitrum) được giới thiệu vào tháng 5 năm 2021, đã được xác minh và thử thách thành công trong môi trường Mạng chính. Mô tả chi tiết về thử thách này có thể được xem tại bài viết của Kroma. Trong trường hợp này, chuỗi Kroma không được Rollback, chỉ xóa phần gốc đầu ra không chính xác.

免责声明：bằng chứng gian lận还是故障证明？

Bằng chứng gian lận còn được gọi là bằng chứng lỗi. Đặc biệt, trong các chuỗi Optimism và OP Stack, thuật ngữ được sử dụng là 'bằng chứng lỗi', trong khi trong các dự án Arbitrum, Cartesi, L2Beat và các dự án khác, thuật ngữ được sử dụng là 'bằng chứng gian lận'.

Xét đến trường hợp nghi ngờ Kroma đã nói ở trên, có thể suy luận rằng nghi ngờ thường bắt nguồn từ “lỗi”, chứ không phải là nỗ lực cố ý thao túng rút tiền. Trong trường hợp ở trên, nguyên nhân chính là sự bất thường của khách hàng L1 do Người xác thực Kroma quan sát. Nói cách khác, đôi khi nghi ngờ chỉ xảy ra do lỗi hoặc sự cố không đúng cách của Người xác thực. Trong trường hợp như vậy, việc sử dụng thuật ngữ “chứng minh lỗi” có thể phù hợp hơn.

Tuy nhiên, thuật ngữ phản ánh mục đích của nó hơn là "bằng chứng gian lận". Tất cả các cơ chế đã được giới thiệu cho đến nay và các cơ chế sẽ được giới thiệu trong tương lai đều nhằm xác minh "hành vi gian lận" của các đầu ra độc hại cố gắng đánh cắp tiền trong cầu.

Vấn đề là trong khi mục đích là để ngăn chặn gian lận, trong thực tế, nghi ngờ có thể được kích hoạt bởi những sai lầm. Trong bài viết này, tôi sẽ sử dụng "bằng chứng gian lận", một thuật ngữ được sử dụng rộng rãi hơn trong hệ sinh thái.

3. Tấn công của Hacker! - Sử dụng cơ chế bằng chứng gian lận

3.1. Thiết kế giao thức tranh chấp kinh tế

Mỗi Optimistic Rollup đều thực hiện cơ chế bằng chứng gian lận và cơ chế nghi ngờ riêng để bảo vệ tài sản của người dùng. Mục tiêu chung của những cơ chế này là "chỉ cần có ít nhất một bên tham gia trung thực, giao thức sẽ duy trì an toàn". Bằng chứng gian lận là bằng chứng cho thấy hàm chuyển trạng thái đã được thực thi đúng như dự đoán, và qua quá trình xác minh, kết quả cuối cùng sẽ là chiến thắng của bên tham gia trung thực.

Tuy nhiên, điều này không phải lúc nào cũng đúng. Trên thực tế, ngay cả khi có những người tham gia trung thực, cũng có thể xảy ra tình huống nguy hiểm cho giao thức. Ví dụ, do bằng chứng gian lận rất phức tạp, có thể xảy ra những lỗ hổng không ngờ, và người tham gia bất lương có thể có lợi về mặt kinh tế so với người tham gia trung thực do sự không cân bằng về cơ chế kích thích, dẫn đến việc người dùng rút tiền bị Trễ đáng kể hoặc tiền bị đánh cắp.

因此，设计bằng chứng gian lận和质疑机制是一项非常困难的任务。特别是，要成为阶段2 Rollup，质疑机制必须是完美的，并且要有应对各种Vectơ tấn công和漏洞的对策。

Nói cách khác, mỗi bằng chứng gian lận và cơ chế nghi ngờ đều cần xem xét cách ứng phó với Vectơ tấn công. Nếu không hiểu rõ từng Vectơ tấn công, thì không thể hiểu tại sao giao thức phải được thiết kế theo cách này.

Do đó, trong phần này, chúng tôi sẽ trước tiên nghiên cứu Vectơ tấn công sau đó khám phá cách mà các giao thức đối phó với các cuộc tấn công này:

Do các cuộc tấn công gây ra bởi các lỗ hổng trong trò chơi gây tranh cãi;
Các cuộc tấn công Trễ sẽ kéo dài thời gian rút tiền của người dùng lên hơn 7 ngày;
Cuộc tấn công Sybil tiêu tốn tài nguyên và nguồn lực của người tham gia thành thật;
Tấn công do L1 Người xác thực gây ra;
Tấn công bằng lỗ hổng trong Máy ảo được thực hiện bằng chứng gian lận.

Lưu ý: Tất cả các Vectơ tấn công được thảo luận dưới đây đều là những thông tin công khai đã biết và sẽ không ảnh hưởng đến bất kỳ sự an toàn nào của Mạng chính.

Các chương tiếp theo sẽ phân tích các giao thức và đặc điểm riêng của chúng như sau:

3.2. Vectơ tấn công #1: Sử dụng trò chơi tranh chấp kinh tế

Hầu hết các Rollup lạc quan đã triển khai cơ chế bằng chứng gian lận đều yêu cầu phải sử dụng phương pháp chia đôi để tìm điểm đầu tiên không khớp. Giao thức phải cung cấp động lực, khuyến khích người tham gia hành động trung thực, điều này rất quan trọng.

Để đạt được mục tiêu này, một trong những cách đơn giản nhất là khi người tham gia hành động sẽ thế chấp một số tiền nhất định (Ký quỹ), nếu họ bị xem xét là có hành vi ác ý, họ sẽ bị phạt Ký quỹ.

Từ góc nhìn lý thuyết trò chơi, giao thức phải đảm bảo số tiền mà kẻ tham gia xấu tính phải tiêu hao cho cuộc tấn công lớn hơn số tiền mà kẻ tham gia trung thành phải tiêu hao cho cuộc phòng vệ. Tuy nhiên, điều này rất khó thực hiện.

Lý do quan trọng ở đây là trong môi trường cạnh tranh, trước khi hoàn thành sự đặt câu hỏi, không thể biết trước ai là người tham gia độc hại. Nói cách khác, người khẳng định đầu ra có thể là người tham gia độc hại, người nghi ngờ đầu ra cũng có thể là người tham gia độc hại. Do đó, giao thức phải được thiết kế trên cơ sở giả định rằng bất kỳ bên nào cũng có thể là người tham gia độc hại. Ngoài ra, do có thể tồn tại nhiều vectơ tấn công khác nhau, việc thiết kế giao thức trở nên vô cùng phức tạp.

Bởi vì mỗi giao thức sử dụng một cơ chế khác nhau, điều quan trọng là phải xác định các vectơ tấn công và mô hình khuyến khích cho những kẻ tấn công tương ứng với từng phương thức. Ngoài ra, một mô hình an toàn kinh tế phải được thiết kế để đảm bảo rằng nó vẫn an toàn ngay cả khi các mô hình này được kết hợp.

Chủ đề này vẫn đang được thảo luận. Trong phần này, chúng tôi sẽ phân tích Vectơ tấn công có thể xảy ra phổ biến và động cơ của các bên tham gia trong những tình huống này. Ngoài ra, chúng tôi cũng sẽ xem xét cách mà mỗi giao thức đối phó với những cuộc tấn công này và mức độ mà chúng hạn chế động cơ này.

3.2.1. Vectơ tấn công #1-1: Tấn công Trễ

Trễ tấn công là khi thực thể độc hại không nhằm mục đích lấy cắp tiền Rollup, mà là để ngăn chặn hoặc trễ việc xác nhận giao dịch trên L1. Cuộc tấn công này có thể xảy ra trong hầu hết các Optimistic Rollup hiện tại, làm cho thời gian rút tiền kéo dài hơn, khiến người dùng phải chờ đợi hơn một tuần để rút tiền từ L1.

Điều này khác với cuộc tấn công do xác thực L1 gây ra, sẽ được thảo luận sau. Xét duyệt ngăn chặn người tham gia trung thực thực hiện bất kỳ hành động nào trên ETH, cho phép xác nhận cuối cùng của gốc trạng thái độc hại. Trong khi đó, cuộc tấn công Trễ có thể trì hoãn xác nhận cuối cùng của gốc trạng thái ngay cả khi người tham gia trung thực tích cực tham gia. Trong trường hợp này, rút tiền của người dùng không chỉ có thể bị trì hoãn, mà nếu số tiền của kẻ tấn công lớn hơn số tiền của người phòng thủ, gốc trạng thái độc hại có thể được xác nhận cuối cùng, dẫn đến việc mất cắp tiền của người dùng.

Một trong những cách đơn giản nhất để ngăn chặn tấn công Trễ là yêu cầu các bên tham gia hệ thống nộp một số tiền cố định hoặc Ký quỹ, nếu họ bị nghi ngờ gây ra Trễ, họ có thể bị phạt Ký quỹ đó.

Tuy nhiên, cần xem xét một số yếu tố. Nếu kẻ tấn công không sợ bị phạt tiền, vẫn cố gắng thực hiện cuộc tấn công trễ, phải làm gì?

这个Vectơ tấn công相当棘手。这也是为什么 Arbitrum 的bằng chứng gian lận系统目前在许可结构中运行的原因。

Cơ chế bằng chứng gian lận được áp dụng cho Arbitrum One và Arbitrum Classic sử dụng mô hình phân nhánh. Thay vì cho phép người tham gia chỉ trích các tuyên bố không chính xác, thì mỗi người tham gia sẽ nộp tuyên bố mà họ cho là chính xác và đính kèm một số tiền, coi chúng như là 'fork của chuỗi'. Tuyên bố cũng có thể được xem như là điểm kiểm tra trạng thái chuỗi.

Mô hình nhánh của Arbitrum

Trong Arbitrum Classic, người tham gia sẽ gửi các tuyên bố và nhánh chuỗi mà họ cho là chính xác, thông qua việc tranh cãi và loại bỏ các nhánh chuỗi không chính xác dần dần, cuối cùng xác nhận tuyên bố chính xác.

Tuy nhiên, một lần nghi ngờ không thể xác định ai là đúng. Hai bên tham gia có thể chia nhầm theo cách sai lệch, định nghĩa các điểm không liên quan như những điểm không nhất quán, từ đó loại bỏ các tuyên bố đúng. Do đó, Arbitrum đảm bảo rằng quá trình nghi ngờ tiếp tục diễn ra cho đến khi không có bên tham gia nào đặt cược tiền vào tuyên bố cụ thể, đảm bảo rằng nếu có ít nhất một bên tham gia trung thực, thì quá trình nghi ngờ có thể được giải quyết thành công.

Điều này có thể bị lạm dụng để tấn công Trễ. Giả sử có người tham gia trung thực và N-1 kẻ tấn công độc ác đặt cược tiền đúng, trong khi một kẻ tấn công đặt cược tiền sai. Nếu kẻ tấn công có thể luôn luôn gửi giao dịch của họ trước người tham gia trung thực, họ có thể đầu tiên nâng cao sự nghi ngờ. Trong trường hợp tồi tệ nhất, nếu họ phân chia sai lầm, chia phần đồng thuận của họ thay vì phần không đồng thuận, họ có thể gửi bằng chứng gian lận ở phần sai. Tự nhiên, điều này sẽ được thông qua, dẫn đến việc người đặt cược đúng thất bại.

Vì mỗi câu hỏi có thể mất đến 7 ngày để giải quyết, kẻ tấn công có thể kéo dài thời gian Trễ của giao thức lên đến 7 * (N-1) ngày.

Cuộc tấn công Trễ của Arbitrum Classic | Nguồn: L2Beat Medium

Vấn đề của cơ chế này là chi phí của cuộc tấn công trễ tăng lên theo thời gian trễ của giao thức. Nếu kẻ tấn công nhận ra rằng cuộc tấn công này có thể mang lại lợi nhuận, họ sẽ cố gắng kéo dài thời gian trễ của giao thức càng lâu càng tốt, và tổng thời gian trễ sẽ tương ứng với tổng số tiền của kẻ tấn công, điều này có thể dẫn đến thời gian rút tiền của người dùng rất lâu.

Tóm lại, một giao thức bằng chứng gian lận có khả năng ngăn chặn tấn công Trễ một cách hiệu quả phải được thiết kế sao cho thời gian trễ tối đa được giới hạn trong một phạm vi nhất định hoặc cơ chế tăng lên theo thời gian, từ đó làm cho chi phí thực hiện tấn công lớn hơn động lực tấn công.

3.2.2. Vectơ tấn công #1-2: Tấn công Sybil (tấn công tài nguyên cạn kiệt)

Một Vectơ tấn công khác là cuộc tấn công Sybil (cuộc tấn công tài nguyên, tấn công cá voi). Khi tài chính hoặc tài nguyên tính toán của kẻ tấn công vượt qua người phòng thủ, điều này sẽ xảy ra. Kẻ tấn công có thể liên tục gửi các gốc đầu ra không chính xác hoặc tạo ra các thắc mắc vô nghĩa, dẫn đến việc tiêu tốn các tài nguyên tài chính hoặc tính toán của người phòng thủ. Tại một thời điểm nào đó, người phòng thủ sẽ hết tiền hoặc tài nguyên tính toán trống rỗng, không thể tiếp tục phòng thủ, trong khi kẻ tấn công sẽ cuối cùng xác định được gốc đầu ra không chính xác và đánh cắp tiền.

Thường thì, Vectơ tấn công được đề cập trên có thể xảy ra trong hệ thống không được cấp phép theo hai cách sau:

Tiếp tục nộp đầu ra không chính xác. Giả sử số tiền của kẻ tấn công Bob vượt quá tổng số tiền của các người tham gia trung thực (người phòng thủ) Alice, Charlie và David. Trong trường hợp này, Bob liên tục nộp đầu ra không chính xác. Người tham gia trung thực Alice, Charlie và David sẽ phản ứng bằng cách thanh toán phí gas và tiền đặt cọc, và ở một ngưỡng nào đó, số tiền của người tham gia trung thực sẽ cạn kiệt trước Bob. Lúc này, Bob nộp một đầu ra không chính xác khác, vì không còn người tham gia trung thực nào trong mạng có số tiền còn lại, đầu ra này sẽ cuối cùng được xác định mà không bị nghi ngờ. Như vậy, Bob có thể đánh cắp tiền từ optimistic rollup.
** Gửi nhiều thắc mắc đến trung thực ** Thay vào đó, kẻ tham gia ác ý có thể tấn công kẻ tham gia trung thực bằng cách gửi nhiều thắc mắc. Tương tự, cuộc tấn công sẽ tiếp tục cho đến khi kẻ tham gia trung thực tiêu hết tất cả các nguồn lực được sử dụng cho phí gas và tiền đặt cọc, sau đó kẻ tấn công ác ý sẽ gửi đầu ra không chính xác và đánh cắp tiền của người dùng từ cầu.

Để ngăn chặn loại tấn công này, cần thiết kế một cách hợp lý lợi thế của người phòng thủ trước kẻ tấn công. Trong mọi trường hợp, người phòng thủ phải có đủ lợi thế trước kẻ tấn công. Một cách để làm được điều này là thiết kế cẩn thận tiền đặt cọc; vì tấn công Sybil liên quan đến tổng số tiền mà mỗi người tham gia có sẵn, nếu tiền đặt cọc được thiết lập đúng, có thể xác định rằng hệ thống là an toàn khi tổng số tiền của kẻ tấn công không vượt quá N lần tổng số tiền của người phòng thủ.

Một phương pháp đã biết khác để ngăn chặn cuộc tấn công Sybil là triển khai giao thức chống lại Sybil tranh cãi. Trong các phần tiếp theo, chúng tôi sẽ tiếp tục giới thiệu Cartesi Dave.

让我们看看每个giao thức如何通过各自的设计来应对这些Trễ和 Sybil 攻击。

3.3. Giải pháp #1: Trò chơi tranh chấp kinh tế lành mạnh

1） Arbitrum BoLD

Dựa trên mô hình nhánh của Arbitrum Classic, BoLD đã đưa vào ba yếu tố sau để ngăn chặn lỗ hổng tấn công trễ:

Tất cả đối với cơ chế nghi ngờ. Trong BoLD, việc nghi ngờ không còn được tiến hành theo cặp đôi mà là một hệ thống tất cả đối với tất cả song song mà các bên tham gia có thể đặt cược tiền vào nhánh mà họ đồng ý. Điều này ngăn chặn các vectơ tấn công TrễVectơ tấn công được tạo ra từ việc nghi ngờ từng cặp đôi trước đây và đảm bảo rằng không thể có nhiều nghi ngờ độc lập với cùng một tranh chấp.
Chứng minh được tính toán bằng trạng thái chính xác ngăn chặn phân chia độc hại (Cam kết lịch sử). Vấn đề trong Arbitrum Classic là người tham gia độc hại có thể phân chia một cách sai lầm, cố ý gây Trễ, đánh dấu phần không tranh chấp như là điểm tranh chấp. Để làm điều này, BoLD yêu cầu chứng minh được gửi kèm với gốc trạng thái, xác minh rằng gốc trạng thái đã được tính toán đúng trong quá trình phân chia, đảm bảo không có phân chia độc hại xảy ra.

Trong BoLD, người tham gia phải gửi bằng chứng và root trạng thái trong quá trình chia đôi. Bằng chứng này xác minh xem root trạng thái hiện tại có được tính toán đúng dựa trên root trạng thái đã gửi trước đó hay không. Nếu người tham gia hiếu kỳ cố gắng gửi một root bất kỳ không liên quan đến root trạng thái đã gửi trước đó trong quá trình chia đôi, quá trình xác minh bằng chứng sẽ thất bại, dẫn đến giao dịch chia đôi thất bại. Điều này hiệu quả đảm bảo rằng mỗi tuyên bố chỉ có thể xảy ra một loại chia đôi.

Do đó, nếu tấn công muốn phân chia tài sản thành nhiều lần trong BoLD, họ phải nộp nhiều tuyên bố.

Tuy nhiên, để tạo ra lời giải thích này, Người xác thực cần sử dụng khá nhiều tài nguyên tính toán. Nội bộ, việc tạo ra lời giải thích này yêu cầu tạo ra Hàm băm cho tất cả các trạng thái trong phân chia hai. Trong Arbitrum, thường cần khoảng 270 Hàm băm để tạo ra lời giải thích này (khoảng 1,18 x 10²¹). Để giải quyết vấn đề này, BoLD chia các câu hỏi thành ba cấp độ, giảm số lượng Hàm băm cần tính toán xuống còn 226 (khoảng 6,71 x 10⁷).

(Biểu đồ này giả định tổng cộng có 269 chỉ thị, dữ liệu thực tế có thể khác nhau)

Thời gian thế chấp được hạn chế thông qua cơ chế đồng hồ cờ.

Trong Arbitrum Classic trước đó, thời gian kéo dài của sự nghi ngờ không có giới hạn thời gian, cho phép những người tham gia có ý đồ xấu có thể kéo dài giao thức một cách vô thời hạn nếu có đủ vốn. BoLD đã giới thiệu cơ chế đồng hồ cờ, hiệu quả hạn chế thời gian kéo dài của sự nghi ngờ.

Giả sử có hai người tham gia đã đệ trình các tuyên bố khác nhau. Mỗi người tham gia đều có một đồng hồ bấm giờ (đồng hồ cờ), thời gian là 6,4 ngày. Khi đến lượt một người tham gia đệ trình bằng chứng hoặc chứng minh, đồng hồ bắt đầu đếm ngược và dừng lại sau khi người tham gia hoàn thành nhiệm vụ.

Do vì mỗi người tham gia đều có 6.4 ngày nên thời gian tối đa mà một người tham gia có thể Trễ quá trình là 6.4 ngày. Do đó, trong BoLD, thời gian kéo dài tối đa của việc đặt câu hỏi là 12.8 ngày (trong một số trường hợp, khi ủy ban an toàn can thiệp, thời gian có thể tăng thêm 2 ngày).

Qua cơ chế này, Arbitrum BoLD hiệu quả hạn chế độ trễ do sự nghi ngờ gây ra. Thời gian nghi ngờ tối đa là hai tuần và độ trễ phụ thêm tối đa mà người dùng có thể trải qua là khoảng một tuần.

Tuy nhiên, điều này có thể được lợi dụng để thực hiện cuộc tấn công Trễ. Kẻ tham gia độc ác có thể tạo ra một câu hỏi và âm mưu với Người xác thực L1, kiểm tra Người xác thực trung thực trên Arbitrum, làm cho việc rút tiền của người dùng Arbitrum trễ lên đến một tuần. Trong trường hợp này, người dùng yêu cầu rút tiền trong thời gian này có thể đối mặt với chi phí cơ hội do tiền bị khóa. Mặc dù đây không phải là một cuộc tấn công mà kẻ tấn công trực tiếp thu lợi từ tiền, nhưng vì gây ra chi phí cơ hội cho người dùng, nên vẫn cần phòng ngừa. Arbitrum BoLD đang xử lý vấn đề này bằng cách đặt cọc đủ cao để tạo ra câu hỏi, nhằm ngăn chặn loại tấn công này.

Arbitrum 在 BoLD 的经济文件中计算了这个金额。giao thứcTrễ的主要原因是 L1 Người xác thực的审查。在Trễ攻击的情况下，情景将如下展开：

Kẻ tấn công gửi một khai báo N' không khớp với khai báo N hiện có trên Arbitrum trước khi xác nhận nó.
Người phòng vệ cố gắng gửi giao dịch phân tách, nhưng do L1 Người xác thực đang xem xét giao dịch nghi ngờ của người phòng vệ, thao tác này thất bại.
Doanh nghiệp có thể xác nhận cuối cùng bị trễ tối đa một tuần do giả định kiểm tra BoLD không thể kéo dài quá 7 ngày.

Lợi nhuận của kẻ tấn công đến từ chi phí cơ hội mà người dùng nghi ngờ yêu cầu rút tiền đã tạo ra. Tình huống tồi tệ nhất là tất cả các quỹ trong Arbitrum đều được rút ra trong một yêu cầu rút tiền, lúc này chi phí cơ hội mà người dùng phải chịu được tính như sau, giả sử TVL của Arbitrum One là 154 tỷ USD, APY là 5%:

Cơ hội chi phí = 15,400,000 x (1.051/52 - 1) = $14,722,400

Vì khả năng mất cơ hội cao khi gửi khai báo không chính xác, người gửi khai báo trong BoLD được yêu cầu nộp một số tiền đặt cọc tương tự. Hiện nay, số tiền đặt cọc yêu cầu cho việc gửi khai báo trong BoLD được đặt là 3600 ETH, tương đương khoảng 9,4 triệu đô la.

Việc làm này nhằm mục đích ngăn chặn kẻ tấn công gây ra tổn thất lớn cho hệ thống thông qua Trễ. Vì kẻ tấn công sẽ mất tiền đặt cược khi bị nghi ngờ, họ có thể gây ra chi phí cơ hội lên tới 14,7 triệu đô la Mỹ, nhưng sẽ mất khoảng 9,4 triệu đô la Mỹ. Do đó, BoLD kiểm soát cuộc tấn công Trễ bằng cách yêu cầu tiền đặt cược tương đương với chi phí cơ hội trong trường hợp xấu nhất.

Tuy nhiên, số tiền đặt cược 3600 ETH không chỉ được thiết lập vì cuộc tấn công Trễ. Để ngăn chặn cuộc tấn công Sybil, Arbitrum BoLD có thể đảm bảo rằng hệ thống sẽ được bảo vệ trước khi tổng số tiền của kẻ tấn công là 6,5 lần tổng số tiền của người bảo vệ, đó chính là cơ sở xác định số tiền đặt cọc 3600 ETH.

Từ góc độ của cuộc tấn công Sybil, các tình huống tấn công sau có thể xảy ra trong Arbitrum BoLD. Hệ thống BoLD có ba cấp độ, người dùng phải khóa tiền để gửi những tuyên bố họ cho là đúng.

Giả sử người tham gia trung thực Alice đã đệ trình một tuyên bố hợp lệ với số tiền là X ETH. Người tham gia xấu tính Bob sở hữu 3600 ETH có thể tạo nhiều tuyên bố xấu tính. Khi đó, Alice cần khóa Y ETH ở tầng thấp hơn cho mỗi tuyên bố của Bob.

Trong mô hình phân nhánh của Arbitrum, việc khóa tài chính có nghĩa là đồng ý với trạng thái chuỗi từ khởi tạo đến khai báo. Đặc điểm này cho phép các bên tham gia chuyển khoản tiền thế chấp của họ từ khai báo A sang các khai báo con A' và A''. Do đó, Alice chuyển X ETH mà cô đã thế chấp ban đầu của mình xuống tầng thấp và khóa Y ETH cho mỗi khai báo xấu của Bob.

Nếu số tiền của Bob rõ ràng nhiều hơn Alice, điều gì sẽ xảy ra? Bob có thể tạo ra vô số tuyên bố xấu, cho đến khi số tiền của Alice cạn kiệt và không thể tiếp tục khóa. Lúc đó, Alice sẽ không thể tiếp tục phân chia, cho phép Bob xác nhận các tuyên bố không chính xác.

Cuối cùng, vấn đề này được coi là mức độ ưu thế của người phòng thủ so với kẻ tấn công trong trò chơi.

Arbitrum gọi chỉ số này là tỷ lệ tài nguyên. Nó cho thấy mức độ ưu thế của các người tham gia trung thực so với các người tham gia độc hại. Tỷ lệ này được biểu thị bằng tỷ lệ giữa phí gas (G) và số tiền thế chấp (S) mà mỗi người tham gia phải trả, như sau:

Hệ thống nghi ngờ của BoLD được chia thành ba cấp độ, đảm bảo rằng người bảo vệ luôn có ưu thế N lần so với kẻ tấn công trong toàn bộ hệ thống bằng cách duy trì tỷ lệ tài nguyên này ở mỗi cấp độ. Arbitrum đã tính toán lượng tiền đặt cọc cần thiết ở cấp độ cao nhất và vẽ biểu đồ.

(Tỷ lệ chi phí thế chấp tranh chấp tầng trên và tài nguyên của Arbitrum BoLD | Nguồn: Desmos）

The chart shows that when the resource ratio is 100 times, the top-level required collateral exceeds 1 million ETH (over 4 trillion USD). While a higher resource ratio makes the system more secure against Sybil attacks, the collateral amount becomes so high that almost no one can participate in the system, making it indistinguishable from a centralized system with only one Người xác thực submitting statements.

Vì vậy, trong BoLD, tỷ lệ tài nguyên được đặt là 6,5 lần, làm cho tiền đặt cọc của tầng trên là 3600 ETH, tiền đặt cọc của tầng 1 và tầng 2 lần lượt được đặt là 555 ETH và 79 ETH.

Tóm lại, BoLD đảm bảo người bảo vệ có lợi thế gấp 6,5 lần so với kẻ tấn công bằng cách tính tỷ lệ tài nguyên và thiết lập số tiền thế chấp.

2) Cartesi Dave

Dave của Cartesi đã đề xuất lần đầu trong một bài báo có tên là "Non-Permissive Review Championship" vào tháng 12 năm 2022, sớm hơn bản White Paper đầu tiên của BoLD. Nó nhằm mục đích giữ cho tài nguyên tính toán và tiền của người tham gia trung thực ở ưu thế so với kẻ tấn công. Cấu trúc của Dave tương tự như BoLD, có hai đặc điểm chính:

Tránh phân tách xấu xa bằng cách tính toán chính xác trạng thái chứng minh (cam kết lịch sử).

Tương tự như BoLD, Dave yêu cầu người tham gia tạo ra bằng chứng trong quá trình phân chia để chứng minh rằng họ đã tính toán đúng, từ đó ngăn chặn các hình thức phân chia độc hại. Do đó, hệ thống thẩm tra của Dave cũng được chia thành nhiều cấp độ để tiết kiệm nguồn lực của Người xác thực.

Trong cấu trúc giải đấu, cơ chế tranh luận tuần tự một cặp một cặp được áp dụng.

Sự nghi ngờ của Dave không phải là một lần duy nhất, mà được thực hiện dưới dạng một cuộc thi, như được mô tả trong hình ảnh dưới đây.

Bức tranh trình bày cách nào sự nghi ngờ diễn ra khi kẻ tấn công ác ý nộp bảy tuyên bố sai lầm để nghi ngờ mạng lưới. Do tính chất của cam kết lịch sử, những người tham gia trung thực (được biểu thị bằng màu xanh lá cây) đã được tập hợp lại thành một đội. Trong Dave, họ được tổ chức dưới dạng giải đấu và được sắp xếp theo hình thức minh họa, mỗi người tham gia thực hiện sự nghi ngờ một cách song song. Sự nghi ngờ trong cùng một giai đoạn được thực hiện đồng thời và sau một tuần, khi sự nghi ngờ hoàn thành, người chiến thắng sẽ tiến vào giai đoạn tiếp theo. Trong bức tranh, đội ngũ người tham gia trung thực phải trải qua ba vòng sự nghi ngờ mới có thể giành chiến thắng trong giải đấu.

Tính năng này rất hiệu quả trong việc ngăn chặn cuộc tấn công Sybil. Đầu tiên, kẻ tấn công phải tạo ra nhiều tuyên bố để thực hiện cuộc tấn công Sybil, mỗi tuyên bố đều tiêu tốn một lượng lớn tài nguyên tính toán và vốn của kẻ tấn công.

Bài báo của Cartesi đã chứng minh rằng, trong mọi trường hợp, người phòng thủ luôn giữ ưu thế số mũ so với kẻ tấn công. Nói cách khác, Dave đảm bảo có thể sử dụng tài nguyên logarit của số lượng kẻ tấn công để phòng thủ trước cuộc tấn công Sybil. Điều này làm cho việc thực hiện cuộc tấn công Sybil trong Dave trở nên rất khó khăn, vì vậy số tiền đặt cược của Dave được thiết lập là tối thiểu 1 ETH, thấp hơn rất nhiều so với số tiền trong BoLD.

Tuy nhiên, Dave dễ bị tấn công Trễ. Mỗi giai đoạn của giải đấu tốn đi một đơn vị thời gian nghi ngờ (một tuần), vì vậy mà càng có nhiều tuyên bố xấu, thì giao thức Trễ càng dài. Thời gian cần thiết để giải quyết một sự nghi ngờ hoàn toàn trong Dave có thể được biểu diễn bằng công thức sau:

Td = 7 x log2(1 + NA)(ngày)

Trong đó, NAN_ANA đại diện cho số lượng tuyên bố độc hại. Tuy nhiên, các thắc mắc của Dave có thể bao gồm nhiều cấp độ để tạo ra cam kết lịch sử hiệu quả. Ở đây, tham gia độc hại có thể tạo ra NAN_ANA tuyên bố độc hại trong mỗi cấp độ thắc mắc này, điều này sẽ làm tăng tổng thời gian Trễ như sau:

Td = 7 x [log2(1 + NA)]L(天数)

Trong đó LL đại diện cho số lượng cấp độ trong mỗi khiếu nại. Nếu như hình trên, có bảy tuyên bố xấu và L=2, thì việc giải quyết hoàn toàn khiếu nại có thể mất đến 9 tuần, người dùng sẽ phải chịu thêm 2 tháng rút tiềnTrễ. Nếu số lượng cấp độ tăng lên hoặc số lượng tuyên bố xấu tăng lên, Trễ có thể kéo dài thêm vài tháng.

Cartesi nhằm mục đích sử dụng chứng minh không cần biết (ZK) để giải quyết vấn đề này, thảo luận chi tiết sẽ được thực hiện trong phần 4 "Cải tiến khả thi".

3）Chứng minh lỗi lạc quan (Optimism Fault Proof, OPFP)

OPFP là một giao thức phi cấp phép, hiện đang được áp dụng trong ứng dụng OP Mạng chính, với những đặc điểm sau:

Tất cả các cơ chế đa nhiệm đối nghiệm bằng cấu trúc cây trò chơi

OPFP cho phép bất kỳ ai cũng có thể gửi đầu ra (khai báo gốc) bất cứ lúc nào. Người xác thực không đồng ý với đầu ra đã được gửi có thể cần tạo ra một quá trình phân chia để thách thức nó.

OPFP Cấu trúc của cây trò chơi và quá trình chia nhị phân | Nguồn: Tài liệu của Optimism

Quá trình chia đôi diễn ra đồng thời trên cây trò chơi được hiển thị ở trên. Các lá của cây biểu thị trạng thái của L2, mỗi nút trên cây tương ứng với một trạng thái trong L2, lá bên phải cùng biểu thị trạng thái L2 mới nhất. Ví dụ, việc tuyên bố tại Nút 1 và việc tuyên bố tại Nút 31 là tương đương.

Cấu trúc này cho phép biểu diễn nhị phân. Ví dụ, nếu một Người xác thực không đồng ý với khẳng định gốc (Nút 1), họ sẽ gửi một khẳng định tại Nút 2, tương ứng với Nút 23 trong cây vì nó là điểm giữa giữa Nút 16 và Nút 31. Người gửi của Nút 1 sau đó sẽ kiểm tra trạng thái L2 của Nút 23, nếu đồng ý, thì gửi Nút 6 (Nút 27); nếu không đồng ý, thì gửi Nút 4 (Nút 19), tiếp tục quá trình này cho đến khi gặp sự khác biệt.

Ngay cả khi có nhiều hướng phân chia trong một trò chơi, chúng cũng có thể diễn ra đồng thời và bất kỳ ai cũng có thể tham gia quá trình phân chia, không chỉ là người gửi đầu ra.

OPFP Cấu trúc hoàn chỉnh của cây trò chơi | Nguồn: Tài liệu lạc quan

OPFP sử dụng cây trò chơi có cấu trúc lồng ghép, cây cấp trên xử lý phân chia cấp Khối, trong khi cây con cấp dưới xử lý phân chia cấp chỉ thị.

Khác với BoLD hoặc Dave, OPFP không áp dụng phân chia đúng sai bằng các cam kết lịch sử, vì chi phí off-chain/on-chain để tạo và gửi các cam kết như vậy là khá cao.

Trò chơi tranh chấp có thể tùy chỉnh dựa trên mô-đun Hiện tại, OP Mạng chính chỉ triển khai hai loại trò chơi tranh chấp (không cấp phép / cấp phép). Optimism dự kiến sẽ cuối cùng giới thiệu nhiều loại trò chơi tranh chấp và đã đạt được giao diện tối thiểu hỗ trợ mục tiêu này. Bằng cách tuân theo tên hàm và tham số cụ thể, bạn có thể tạo ra các trò chơi tranh chấp tùy chỉnh.
Giới hạn thời gian nghi ngờ thông qua đồng hồ cờ

Trong OPFP, khi có sự nghi ngờ, người đề xuất và người nghi ngờ đều sẽ nhận được một chiếc đồng hồ, được phân bổ thời gian để chia đôi. Mỗi lần đề xuất tuyên bố, đồng hồ sẽ bắt đầu đếm giờ đối với đối phương. Optimism gọi đó là "đồng hồ thừa kế của ông".

Thú vị là, mỗi người tham gia được phép có 3,5 ngày thay vì 7 ngày, điều này có nghĩa là nếu không có ai nêu ra bất kỳ thắc mắc nào về đầu ra, đầu ra đó sẽ được xác định cuối cùng trong vòng 3,5 ngày.

Tuy nhiên, điều này không cho phép rút tiền ngay lập tức. Sau khi kết quả cuối cùng được xác định, OPFP sẽ có một giai đoạn bảo vệ trong vòng 3,5 ngày, trong thời gian này, Ủy ban An ninh có thể can thiệp và vô hiệu hóa các kết quả không chính xác khi cần thiết.

Quy trình rút tiền của người dùng trong "Đường dẫn hạnh phúc" | Nguồn: OP Labs Blog

Dựa trên cơ chế này, OPFP và các rollups lạc quan khác đảm bảo rằng người dùng có thể rút tiền ít nhất 7 ngày sau khi gửi. Tuy nhiên, nếu có tranh chấp, người dùng có thể cần phải mất hơn 7 ngày để rút tiền từ đầu ra đó. Mô hình đồng hồ cờ của OPFP giới hạn thời gian mà mỗi bên tham gia có thể dành cho quá trình chia đôi, nhưng không hạn chế nghiêm ngặt tổng thời gian trước khi tranh chấp được giải quyết.

Điều này đặt ra một vấn đề: Nếu có sự nghi ngờ về OPFP, liệu việc rút tiền của người dùng có thể bị trễ hơn một tuần, tương tự như trường hợp của BoLD không? Câu trả lời là "Có". Khác với BoLD hoặc Dave, Optimism cung cấp cho người dùng các lựa chọn để đối phó với tình huống nghi ngờ, dựa trên đặc điểm độc đáo của giao thức.

OPFP hoạt động dựa trên giả định rằng "những người tham gia nộp tuyên bố không chính xác sẽ mất Ký quỹ của họ". Tuy nhiên, trong OPFP có một trường hợp biên giới làm vỡ giả định này, được gọi là "tuyên bố đón đoàn". Trường hợp này có thể xảy ra trong các tình huống sau đây:

Alice đã đệ trình một tuyên bố về trạng thái gốc chính xác.
Bob đã đệ trình một tuyên bố phản bác, trong khi Alice đã thực hiện hành động để bảo vệ tuyên bố ban đầu của mình.
Bob đợi cho đến khi hết hạn hẹn của đồng hồ của mình (khoảng 3,5 ngày), sau đó đặt câu hỏi về tuyên bố của mình.

Tại thời điểm này, Alice nên trả lời và yêu cầu Quỹ Ký của Bob, nhưng cô ấy thừa hưởng thời gian còn lại trên đồng hồ của Bob, điều này có thể không đủ để cô ấy bác bỏ tuyên bố của anh ấy. Do đó, Bob có thể đã tránh được việc mất quỹ Ký của mình bằng cách nộp "tuyên bố người lái tự do".

Tuyên bố hợp tác vào tàu hỏa trong Optimism Fault Proof | Nguồn:L2Beat

Dù điều này không ngăn cản việc nghi ngờ được giải quyết đúng, nhưng thực sự đại diện cho một tình huống, tức là "đã nộp một tuyên bố không chính xác mà không phạt Ký quỹ", từ góc độ khích lệ, tình huống này nên được tránh.

Do đó, nếu thời gian còn lại của người đề xuất hoặc người khẳng định ít hơn 3 giờ, OPFP sẽ giải quyết vấn đề này bằng cách đặt lại đồng hồ thành 3 giờ. Điều này đảm bảo có đủ thời gian để bác bỏ tuyên bố lên xe. Tuy nhiên, nếu trong nửa kỳ tiếp theo không có hành động nào được thực hiện trong hơn 3 giờ, sự tranh luận sẽ kết thúc.

Chúng ta có thể tưởng tượng một tình huống, trong tình huống này, cơ chế này được sử dụng để thực hiện cuộc tấn công Trễ. Giả sử người tham gia trung thực Alice nộp một đầu ra chính xác, từ lúc Alice nộp, đồng hồ của người nghi ngờ bắt đầu đếm ngược. Người tham gia ác ý Bob đợi đến khi đồng hồ của người nghi ngờ còn 1 giây nữa là nộp một đầu ra không chính xác. Lúc này, theo quy tắc của OPFP, thời gian của Bob sẽ được kéo dài thêm 3 giờ. Alice sẽ đáp ứng và Bob sẽ tiếp tục tận dụng thêm 3 giờ cho mỗi lần chia đôi.

Điều này có thể dẫn đến việc hoãn Trễ. Bob có thể hoãn lâu nhất là 3,5 ngày + 3 giờ × số lần chia nhỏ tối đa. MAX_GAME_DEPTH của OPFP là 73, điều này có nghĩa là Bob có thể hoãn quy trình lâu nhất là 3,5 ngày + 3 giờ × 36 = 8 ngày. Nếu Alice cũng thực hiện biện pháp tương tự để hoãn việcTrễ, quá trình chia nhỏ có thể mất 16 ngày.

Điều này có ý nghĩa là người dùng không thể rút tiền trong vòng 16 ngày? Trên thực tế, không phải vì logic rút tiền của Optimism làm cho tình huống này không đúng. Khác với Arbitrum, nơi yêu cầu rút tiền phải chứng minh rằng nó được bao gồm trong một Khối L2 cụ thể, OP Stack sử dụng cơ chế chứng minh lưu trữ, yêu cầu rút tiền được ghi nhận trong hợp đồng L2ToL1MessagePasser trên L2. Điều này có nghĩa là ngay cả khi thời gian tranh chấp của đầu ra cụ thể rất lâu, người dùng vẫn có thể chờ đợi cho đến khi đầu ra tiếp theo hoàn thành và rút tiền dựa trên gốc lưu trữ hợp đồng trong đầu ra đó. Do đó, ngay cả khi Khối rút tiền mà họ yêu cầu bị tranh chấp, người dùng cũng không cần phải trải qua Trễ lâu dài, vì họ có thể sử dụng đầu ra tiếp theo.

Tuy nhiên, tất cả chỉ có thể xảy ra nhanh chóng nếu người dùng hành động nhanh chóng. Trong hầu hết các trường hợp, người dùng có thể phải chịu đựng Trễ trong vài ngày. Điều này có thể được quyết định bởi quy trình rút tiền trong OP Stack, bao gồm chủ yếu ba bước sau:

Bắt đầu rút tiền trên L2 (initiateWithdrawal).
Chứng minh giao dịch rút (proveWithdrawalTransaction) trên L1, bao gồm đầu ra của giao dịch rút tiền.
等待一周的证明成熟Trễ，然后最终完成提现（finalizeWithdrawalTransaction）。

Điểm quan trọng là từ khi chứng thực rút tiền đến khi hoàn tất rút tiền, người dùng phải chờ đợi một tuần. Nếu Alice chứng thực rút tiền trên đầu ra B và có sự nghi ngờ, cô ấy có thể gửi một chứng thực khác cho đầu ra C và hoàn tất rút tiền sau một tuần. Trong trường hợp này, Alice chỉ trải qua trễ giữa đầu ra B và đầu ra C.

Do đó, người dùng không nhận thức được sự đặt nghi vấn hoặc phản ứng muộn hơn có thể trải qua tối đa 9 ngày Trễ rút tiền.

Ngoài ra, OPFP còn có một Vectơ tấn công Trễ bổ sung, nghĩa là mỗi đầu ra đều phải trải qua thế chấp liên tục. Trong trường hợp này, người dùng không thể né tránh Trễ bằng cách chứng minh ở đầu ra tiếp theo, d导致整个giao thức被Trễ. OPFP đối mặt với điều này bằng cách yêu cầu người tham gia thế chấp Ký quỹ ở mỗi cấp độ nhị phân, số lượng Ký quỹ tăng theo cấp số mũ, như hình dưới đây.

OPFP Ký quỹ金额 | Nguồn: Tệp Optimism

Nói cách khác, kẻ tấn công càng cố gắng trì hoãn việc giải quyết truy vấn trong OPFP, chi phí ký quỹ sẽ càng cao, vì yêu cầu ký quỹ tăng theo cấp số nhân, làm giảm động cơ trì hoãn các cuộc tấn công theo thời gian. Ngoài ra, vì đầu ra trong OPFP có thể được cam kết bất cứ lúc nào, kẻ tấn công rất khó ước tính các tài nguyên cần thiết để thực hiện một cuộc tấn công trì hoãn. Ký quỹ ban đầu được đặt ở mức 0,08 ETH, trong khi tổng số tiền ký quỹ phải được gửi trong trường hợp có thử thách đầy đủ lên tới ~ 700 ETH.

Tóm lại, OPFP đặt quyết định về thời gian trễ trong trường hợp tranh cãi một lần cho người dùng, và sử dụng yêu cầu Ký quỹ theo mô hình chỉ số để đối phó với cuộc tấn công trễ do tranh cãi liên tục gây ra. Tuy nhiên, OPFP dễ dàng bị tấn công Sybil. Trong OPFP, nếu số tiền tấn công lớn hơn số tiền phòng thủ, có thể xảy ra tấn công Sybil.

Trong OPFP có thể tồn tại các Vectơ tấn công Sybil sau đây, tất cả đều có thể dẫn đến việc mất tiền của người dùng:

Tấn công tạo ra nhiều nghi ngờ, dẫn đến người phòng thủ sử dụng tất cả vốn cho Ký quỹ và phí Gas.
Tấn công gia liên tục gửi đầu ra không chính xác, buộc người phòng thủ phải phản ứng cho đến khi tiêu tốn hết quỹ Ký quỹ và phí Gas của họ.

Điều này là khả thi trong OPFP vì trong quá trình tranh luận, số lượng Ký quỹ tổng cần thiết cho kẻ tấn công và người phòng thủ gần như tương đương, và tài nguyên người phòng thủ sử dụng (ví dụ như phí Gas hoặc Khả năng tính toán) không đáng kể ít hơn kẻ tấn công.

Tuy nhiên, điều này không có nghĩa là tiền của người dùng trong OP Mạng chính hiện tại đang đối mặt với nguy cơ. OPFP vẫn đang ở giai đoạn 1 và Ủy ban An toàn có quyền sửa chữa bất kỳ kết quả không đúng đắn nào. Do đó, ngay cả khi xảy ra cuộc tấn công như vậy, Ủy ban An toàn cũng có thể can thiệp để bảo vệ tiền của người dùng trên cầu OP Mạng chính.

Tuy nhiên, để chuyển OPFP sang Giai đoạn 2, Optimism đã phải sửa đổi cơ chế để đảm bảo rằng các hậu vệ có lợi thế lớn hơn so với những kẻ tấn công. Optimism đang chuẩn bị Controversy Game V2 để giải quyết vấn đề này, với nhiều chi tiết hơn được đề cập trong Phần 4, "Những cải tiến có thể".

4) Chứng minh sự cố Kroma ZK (Kroma ZKFP)

Kroma là một hệ thống ZK Proof of Stake không cần phép thuộc OP Stack L2. Trước khi OPFP được giới thiệu, Kroma đã ra mắt hệ thống này trên Mạng chính của mình vào tháng 9 năm 2023. Kroma ZKFP có các tính năng tương tự như OPFP, nhưng điểm nổi bật của nó là sử dụng ZK để tạo ra các chứng minh cấp khối và sử dụng phân tích thay vì chia đôi, giảm đáng kể số lần tương tác cần thiết trong quá trình thử thách. Các tính năng chính của Kroma ZKFP được tổng kết như sau:

Giảm số lần tương tác thông qua ZK và phân rã

Kroma ZKFP cho phép các bên tham gia tìm thấy điểm khác biệt trong bốn lần tương tác. Khi đưa ra thắc mắc, Kroma ZKFP xử lý thắc mắc trên 1.800 Khối, từ đầu ra trước đến đầu ra hiện tại. Khác với phương pháp chia đôi, trong phương pháp phân giải, người đề xuất và người góp ý sẽ chia phạm vi thành N phần. Quá trình này như sau:

Sau khi mỗi người tham gia đã gửi hai giao dịch, họ sẽ xác định Khối mà họ có sự khác biệt, người nghi ngờ có thể tạo ra một chứng cứ lỗi ZK để chỉ ra rằng tuyên bố của người đề xuất là sai. Trong Kroma ZKFP, thời gian chờ chia đôi được đặt là 1 giờ, trong khi thời gian chờ tạo chứng cứ ZK là 8 giờ.

通过激励机制实现Người xác thực的Phi tập trung

BoLD và OPFP đều cung cấp động lực cho người chiến thắng, nhưng không cung cấp động lực cụ thể cho người nộp đầu ra. Trên thực tế, bất kỳ ai muốn rút tiền đều có thể nộp đầu ra và trở thành Người xác thực. Tuy nhiên, đối với người dùng muốn rút tiền, việc tự vận hành client Người xác thực là không khả thi và cần có người định kỳ nộp đầu ra để duy trì tính hoạt động. Vì đây là một nhiệm vụ tốn nhiều tài nguyên, cần phải trả phí Gas để nộp đầu ra và vận hành client Người xác thực, do đó nếu không có động lực phù hợp, chỉ có ít người có thể tham gia trở thành Người xác thực, điều này có thể dẫn đến tập trung quá mức cũng như phản ứng không đủ trong tình huống sự cố.

Vì vậy, Kroma đã sửa đổi OP Stack, phân phối một nửa phí Gas được tạo ra on-chain cho Người xác thực nộp đầu ra. Ngoài ra, Kroma dự định chuyển đổi cơ chế thưởng này sang Token KRO nguyên sinh sau TGE, và có kế hoạch giới thiệu hệ thống Người xác thực giống như DPoS để cho phép người dùng thông thường đóng góp vào sự an toàn và tính linh hoạt của chuỗi mà không cần chạy khách hàng của riêng mình.

Ký quỹ trong Kroma hiện đang được thiết lập là 0.2 ETH, đảm bảo nó lớn hơn chi phí tạo ra chứng minh ZK và thực hiện phân chia. Ký quỹ này sẽ được chuyển đổi thành thế chấp KRO trong hệ thống Người xác thực trong tương lai.

Hệ thống thách thức 1v1 đồng thời

Để đảm bảo phân phối công bằng và nhất quán, Kroma sẽ thiết lập khoảng thời gian nộp đầu ra là 1 giờ và ngẫu nhiên chọn Người xác thực từ tập hợp Người xác thực đã đăng ký để đề xuất. Điều này ngăn ngừa các cuộc đua quá mức dẫn đến lãng phí phí Gas và tránh việc người xây dựng Khối có quyền sắp xếp giao dịch độc quyền chiếm đoạt phần thưởng.

Do 01928374656574839201, Kroma ZKFP đang chạy hệ thống tranh chấp 1v1 song song. Khi Người xác thực ngẫu nhiên được chọn nộp đầu ra, bất kỳ ai cũng có thể khởi xướng tranh chấp, với việc chia nhỏ chỉ diễn ra giữa người nộp đầu ra và người tranh chấp. Nhiều tranh chấp có thể diễn ra đồng thời, người tranh chấp đầu tiên nộp chứng minh ZK hợp lệ sẽ chiến thắng tranh chấp.

Thời gian chờ nghiêm ngặt có nghĩa là, ngay cả những kẻ nghi ngờ xấu tính cố gắng thực hiện cuộc tấn công Trễ cũng phải hoàn thành tất cả các phân chia và sinh chứng trong vòng 10 giờ. Ngoài ra, vì những kẻ nghi ngờ bị ép buộc hoàn thành tất cả các hoạt động trong vòng 6 ngày (không bao gồm 1 ngày giám hộ), việc thực hiện cuộc tấn công Trễ thông thường trong Kroma là không thể.

Tuy nhiên, nếu người tấn công có số vốn lớn hơn người phòng thủ, Kroma ZKFP vẫn dễ bị tấn công Sybil, tương tự như OPFP. Trong Kroma ZKFP, tình huống tấn công Sybil có thể như sau:

Kẻ tấn công liên tục nghi ngờ đầu ra hợp lệ cho đến khi người gửi đầu ra cạn kiệt vốn, lúc này kẻ tấn công nộp chứng minh ZK để chiếm đóng sự nghi ngờ.

Tương tự như OPFP, Kroma ZKFP sẽ xóa đầu ra tương ứng sau khi thành công trong việc đặt nghi vấn. Do đó, nếu có cuộc tấn công như vậy xảy ra, đầu ra có thể bị xóa, dẫn đến việc rút tiền bị Trễ lên đến 1 giờ. Nếu cuộc tấn công tiếp tục diễn ra, tất cả các Người xác thực trung thực có thể bị thiếu hụt vốn, dẫn đến việc xác nhận cuối cùng của đầu ra sai lầm, qua đó cho phép kẻ tấn công có thể đánh cắp tiền của người dùng.

Ngoài ra, Kroma ZKFP vền ồn độ 0 vì hệ thống chứng minh chưa hoàn thiện, lý do như sau:

Điểm bắt đầu của phân chia dựa trên đầu ra cuối cùng được gửi, chứ không phải là đầu ra cuối cùng được xác nhận.

Trong OPFP, điểm khởi đầu của việc chia là đầu ra xác nhận cuối cùng khoảng một tuần trước. Tuy nhiên, trong Kroma ZKFP, điểm khởi đầu là đầu ra được gửi cuối cùng, được gửi khoảng 1 giờ trước và quá trình chia kéo dài trên 1.800 Khối.

Điều này có thể cho phép người nghi ngờ thắng trong trường hợp các đầu ra trước đó bị xóa vì nghi ngờ. Trong trường hợp này, việc chia đôi sẽ dựa trên thông tin đầu ra trước đó mà người nghi ngờ đã gửi, nếu họ cố tình thao túng thông tin này, họ có thể thắng trong cuộc tranh cãi.

Chưa được xác minh liệu mỗi Người xác thực có đưa ra thắc mắc dựa trên dữ liệu lô hàng đúng hay không.

Mặc dù Kroma ZKFP sử dụng ZK để đảm bảo rằng nếu mạch ZK không có lỗ hổng thì không thể có chuyển tiếp trạng thái sai cuối cùng, nhưng Kroma ZKFP không xác minh xem việc tạo ra chứng thư ZK có dựa trên dữ liệu lô đúng hay không. Điều này có nghĩa là, ngay cả khi một số giao dịch bị loại bỏ hoặc giao dịch sai được bao gồm trong lô, chứng thư ZK vẫn có thể được xác minh.

Do đó, có thể thắng được sự nghi ngờ bằng cách sử dụng chứng minh ZK dựa trên dữ liệu sai lệch và nếu giao dịch rút tiền của người dùng bị loại khỏi quá trình xử lý hàng loạt, rút tiền của họ có thể bị Trễ.

Tuy nhiên, trên thực tế, Ủy ban An ninh có thể can thiệp để rút lại kết quả của thử thách sai hoặc loại bỏ đầu ra không hợp lệ, vì vậy các Vectơ tấn công này sẽ không ảnh hưởng đến tiền của người dùng chính Kroma Mạng. Tuy nhiên, để đạt được Giai đoạn 2, Kroma ZKFP phải thực hiện các cơ chế phòng thủ chống lại các lỗ hổng này. Kroma đã đề xuất các cải tiến để giải quyết những vấn đề này, được mô tả chi tiết trong Phần 4, "Những cải tiến có thể".

3.4 Vectơ tấn công #2：L1 审查

Trước đây, chúng ta đã đề cập đến việc Rollup kế thừa tính an toàn của Ethereum. Điều này có nghĩa là nếu tính an toàn của Ethereum bị ảnh hưởng, Rollup cũng sẽ bị ảnh hưởng.

Có hai kịch bản trong đó tình huống của Ethereum có thể ảnh hưởng đến tính bảo mật của các bản tổng hợp:

Ether坊验证者对 Rollup bằng chứng gian lận交易的审查 Nếu nhà xác thực hoặc xây dựng trên mạng lưới ETH lập kế hoạch cùng nhau và gửi gốc đầu ra độc hại trong Optimistic Rollup, đồng thời kiểm tra tất cả các giao dịch liên quan đến bằng chứng gian lận, thì sẽ xảy ra điều gì? Sự nghi ngờ sẽ không được giải quyết trong khoảng thời gian quy định, đầu ra sẽ được xác nhận và quỹ của người dùng có thể đối mặt với rủi ro. Điều này được gọi là kiểm tra yếu. Trong trường hợp Optimistic Rollup, nếu kiểm tra này kéo dài quá thời gian quy định (thường là 7 ngày), nguy cơ về tài chính của người dùng có thể phát sinh.
Ethereum bị tấn công 51%, dẫn đến việc tất cả các giao dịch gian lận được kiểm tra **Tình huống này liên quan đến hai con đường tấn công có thể xảy ra:

Đầu tiên, một thực thể có thể nhận được hơn 2/3 tổng số thế chấp ETH, điều này sẽ cho họ quyền xác nhận Khối theo ý muốn. Trong trường hợp này, kẻ tấn công có thể xem xét các giao dịch bằng chứng gian lận, thậm chí tạo ra những giao dịch này một cách tự ý.
Phương pháp thứ hai liên quan đến việc một số lượng thế chấp ETH lớn hơn 1/3 của toàn bộ Ethereum tham gia vào cuộc tấn công "ẩn danh". Điều này được mô tả trong nghiên cứu "Tấn công kiểm duyệt không thể dẫn về nguồn gốc đối với các giao thức L2 dựa trên bằng chứng gian lận" tại đây. Trong trường hợp này, kẻ tấn công sở hữu 1/3 thế chấp ETH có thể ngăn chặn xác nhận của bất kỳ Khối nào mà họ không thích. Nếu kẻ tấn công tiếp tục bỏ phiếu cho các Khối thông thường, đồng thời im lặng với các Khối chứa bằng chứng gian lận, họ có thể xác nhận gốc đầu ra độc hại, từ đó đánh cắp tiền từ Optimistic Rollup. Điều này được gọi là tấn công kiểm duyệt không thể dẫn về nguồn gốc đối với L2 dựa trên bằng chứng gian lận. Loại tấn công này khó phát hiện hơn việc đơn giản chỉ cần sở hữu hơn 2/3 thế chấp và kiểm soát tất cả các Khối Ethereum.

Những cuộc tấn công dựa trên kiểm duyệt là khó khăn để đối phó ở tầng Rollup, vì chúng xảy ra trên lớp giao thức Ethereum, điều này yêu cầu cải tiến về mặt Ethereum chính nó. Tuy nhiên, Rollup có thể áp dụng một số chiến lược trong thời gian này.

3.5 Giải pháp #2: Phục hồi rủi ro trễ rút tiền trong 7 ngày và tấn công 51% bán tự động

Để đối phó với Vectơ tấn công này, Optimistic Rollup hiện đang thực hiện việc rút tiền Trễ trong 7 ngày. Ý tưởng ban đầu cho 7 ngày này được đề xuất bởi Vitalik, dựa trên ý tưởng rằng 7 ngày là đủ để đối phó với các cuộc tấn công kiểm duyệt.

Hãy phân tích xem giai đoạn 7 ngày nghi ngờ của Optimistic Rollup có đủ để chống lại cuộc tấn công kiểm duyệt hay không, sẽ xem xét hai loại kiểm duyệt: kiểm duyệt yếu và kiểm duyệt mạnh.

Đối với kiểu kiểm duyệt yếu thứ nhất, chúng ta có thể sử dụng tính toán xác suất để xem xét xem trong vòng 7 ngày có khả năng Optimistic Rollup chống lại cuộc tấn công kiểm duyệt hay không. Điều này liên quan đến việc tính toán xác suất thành công trong việc nghi ngờ gian lận khi một số người xác thực kiểm duyệt Rollup.

Ở đây, cần xem xét hai yếu tố:

Để thành công trong việc tranh chấp trong vòng 7 ngày, phải có nhiều giao dịch thành công.

Trong hầu hết các giao thức, nếu chỉ có một giao dịch từ người tham gia trung thực được bao gồm trong tuần này, thì việc nghi ngờ sẽ không thành công. Do đó, chúng ta cần tính xác suất tất cả các giao dịch cần thiết để gửi bằng chứng gian lận trong vòng 7 ngày được bao gồm.

Phải giả định tỷ lệ Người xác thực liên quan đến kiểm tra là hợp lý. Hiện tại, phần lớn các nhà xây dựng khối ETH Fang (được biết là tập trung) không bị kiểm duyệt và với tỷ lệ phần trăm người đặt cọc solo trên ETH Square, cơ hội của đại đa số (ví dụ: 99,9%) Người xác thực thông đồng với kiểm duyệt gần như bằng không.

（Đánh giá của Ethereum Khối xây dựng chính | Nguồn: Tweet của Justin Drake）

Với hai điều này trong tâm trí, nếu chúng ta giả sử rằng 99,5% Người xác thực (vẫn là một giả định quá cực đoan) tham gia vào quá trình xem xét và tính toán xác suất thành công của người tham gia trung thực khi gửi 30 đến 40 giao dịch cần được nghi ngờ giao thức (như BoLD hoặc OPFP), thì trong tất cả các trường hợp, xác suất thành công gần như 100%. Ngoài ra, với sự xuất hiện của các giải pháp trong tương lai (như việc liệt kê hoặc nhiều người đề xuất song song, chẳng hạn như BRAID, APS + FOCIL), khả năng chống lại quá trình xem xét có thể được nâng cao hơn, từ đó giảm thiểu rủi ro mất vốn của người dùng do sàn giao dịch Optimistic Rollup yếu điều tra.

Vậy, trong trường hợp kiểm duyệt nghiêm ngặt, 7 ngày có đủ không? Tấn công 51% được đề cập ở trên chỉ có thể được giải quyết thông qua fork xã hội. Cuộc tấn công kiểm duyệt không thể quá rõ ràng, không thể được ngăn chặn thông qua các giải pháp được thiết kế cho kiểm duyệt yếu (như việc thêm vào danh sách).

Có một đề xuất là phát triển một công cụ phục hồi tấn công 51% bán tự động trong phần mềm máy khách, dựa trên cấu trúc được đề xuất bởi Vitalik. Các nhà nghiên cứu của ETH đã tiến hành phát triển giải pháp phát hiện xét duyệt này, chia thành hai bước:

khách hàng ánh sáng监控内存池，检测某些交易在Khối中未被包含的时间是否过长。
Nếu giao dịch cụ thể ở trong memory pool trong một ngày mà không được bao gồm vào Khối, điều này sẽ kích hoạt nút 'Bạn có đồng ý tham gia fork xã hội không?' cho phép cộng đồng khởi động fork cứng dựa trên Nhận thức chung này.

Nếu công cụ này phát hiện được cuộc tấn công 51%, bước tiếp theo sẽ là chuyển sang một fork xã hội mới on-chain để vô hiệu hóa tiền của kẻ tấn công.

Trong tình huống này, số tiền bị ảnh hưởng bởi cuộc tấn công 51% phải được giữ khóa cho đến khi cuộc fork xã hội được thực hiện. Trong thời gian Hard Fork của The DAO, đã xảy ra trường hợp tương tự khi số tiền của Hacker đã bị khóa trong một sub-DAO trong 27 ngày cho đến khi họ có thể rút tiền. Trong thời gian này, cộng đồng Ethereum đã thành công trong việc thực hiện Hard Fork, ngăn chặn Hacker rút tiền (để biết thêm chi tiết, vui lòng xem bài đăng của Vitalik trên Reddit).

Nói cách khác, ngay cả khi xảy ra cuộc tấn công 51%, tiền vẫn phải được giữ khóa cho đến khi có fork xã hội. Trong trường hợp này, thời gian rút tiền 7 ngày trong Optimistic Rollup đóng vai trò làm bộ đệm. Nếu không có fork xã hội trong tuần này, tiền của người dùng trong Optimistic Rollup có thể bị đánh cắp hoặc rút vào sàn giao dịch tập trung, hoặc được trộn qua Tornado Cash, dẫn đến tiền gần như không thể trả lại cho người dùng sau fork xã hội.

Tóm lại, mặc dù thời gian rút tiền 7 ngày trong Optimistic Rollup ban đầu được thiết kế để đối phó với kiểm duyệt yếu, nhưng thực tế khả năng xảy ra kiểm duyệt yếu không lớn, trong khi thời gian 7 ngày này lại đóng vai trò là thời gian đệm trong trường hợp cần phải tạo một fork xã hội trong kiểm duyệt mạnh.

Từ góc độ này, đã có những chỉ trích rằng OPFP đã rút ngắn thời hạn này xuống còn 3,5 ngày, khiến nó dễ bị tấn công kiểm duyệt mạnh hơn. Tuy nhiên, những chỉ trích này là không có căn cứ. Vì Optimism hiện vẫn đang ở giai đoạn 1, người giám hộ có đủ thời gian để xác minh tính chính xác của gốc trạng thái, rút tiền chỉ có thể được thực hiện sau khi kết thúc thêm 3,5 ngày giám hộ. Do đó, ngay cả khi bị tấn công kiểm duyệt mạnh, kẻ tấn công vẫn phải chờ đợi 7 ngày để rút tiền. Ngoài ra, kẻ tấn công cũng phải kiểm tra tất cả các giao dịch liên quan đến sự nghi ngờ trong suốt một tuần để thành công, vì người giám hộ cũng cần được kiểm tra để ngăn chặn họ từ việc xác nhận đầu ra độc hại.

Tuy nhiên, điều quan trọng là ETH cần đảm bảo rằng họ có thể xử lý được sự fork xã hội trong vòng 7 ngày. Điều này có nghĩa là công cụ phát hiện tấn công 51% phải sẵn sàng và cần phải có sự nghiên cứu và mô phỏng đầy đủ để xác định xem họ có thể thực hiện fork xã hội trong vòng 7 ngày hay không. Chỉ khi đó, sự trễ rút tiền trong Optimistic Rollup sau 7 ngày mới có thể được xem là một biện pháp bảo vệ hợp lệ.

3.6 Vectơ tấn công #3：利用bằng chứng gian lận系统中的漏洞

Đa số nghi ngờ giao thức bằng cách cho người tham gia tìm ra một điểm cụ thể (hướng dẫn hoặc Khối), tại điểm đó họ không đồng ý với nhau, sau đó tạo ra bằng chứng, chứng minh rằng lập luận của người tham gia khác là sai. Máy ảo được sử dụng để tạo ra bằng chứng này được gọi là Máy ảo bằng chứng gian lận (Fraud Proof VM), và phần mềm được sử dụng trên Máy ảo này để tạo ra bằng chứng được gọi là chương trình (program). Mỗi giao thức sử dụng Máy ảo bằng chứng gian lận và chương trình khác nhau, như sau:

Mỗi hệ thống bằng chứng gian lận đều được thiết kế để chứng minh rằng kết quả thực thi cụ thể nào đó trong EVM là chính xác trên on-chain. Nhưng nếu hệ thống đó (bản thân Máy ảo hoặc chương trình) có lỗ hổng, điều gì sẽ xảy ra?

Câu hỏi này có thể được khám phá thông qua Vectơ tấn công của Yoav Weiss [tìm thấy trong OVM] (https://medium.com/infinitism/optimistic-time-travel-6680567f1864). Cuộc tấn công có thể xảy ra do lỗ hổng trong tính năng Rollback của OVM, nhưng tiền đề tạo ra một "giao dịch gian lận" là rất quan trọng đối với việc thực hiện cuộc tấn công. Giao dịch gian lận là các giao dịch được thực hiện trong quá trình xử lý bình thường trên Rollup, nhưng tạo ra kết quả khác nhau khi bị thách thức bằng cách sử dụng bằng chứng gian lậnMáy ảo và các chương trình. Vì hệ thống bằng chứng gian lận được cho là tạo ra kết quả tương tự như EVM, nên việc có thể tạo ra các giao dịch gian lận có nghĩa là có một lỗ hổng trong hệ thống bằng chứng gian lận.

Yoav đã phát hiện ra nhiều lỗ hổng trong hệ thống bằng chứng gian lận của OVM và có thể mô phỏng cuộc tấn công này bằng cách tạo ra các giao dịch gian lận. Một ví dụ về cuộc tấn công đơn giản mà anh ấy phát hiện là: trong StateManager của OVM, chi phí gas của Mã thao tác SSTORE và SLOAD (được sử dụng để lưu trữ và đọc trạng thái) bị ghi nhận sai. Điều này có nghĩa là bất kỳ giao dịch nào lưu trữ hoặc đọc giá trị trong hợp đồng (hầu hết các giao dịch, ngoại trừ việc chuyển ETH đơn giản) đều sẽ bị đánh dấu là giao dịch gian lận trong quá trình kiểm tra, ngay cả khi nó được thực hiện đúng đắn trên Rollup.

Tóm lại, nếu hệ thống có lỗ hổng, các thay đổi trạng thái được thực hiện đúng có thể bị đánh dấu là không hợp lệ trong quá trình tranh luận, dẫn đến đầu ra được gửi bởi người tham gia trung thực bị đánh dấu là sai.

Điều này cũng là một trong những lý do mà OP Mainnet gần đây đã chuyển hệ thống bằng chứng lỗi của mình từ chế độ không cần phép sang chế độ chỉ có người tham gia được ủy quyền có thể tham gia. Sau khi áp dụng OPFP vào Mạng chính, cuộc kiểm tra an ninh tiết lộ một số lỗ hổng trong hệ thống bằng chứng gian lận (Cannon và op-program) cũng như trong vài giao thức thách thức trò chơi tranh cãi. Để ngăn chặn việc lợi dụng hệ thống, Optimism đã tuyên bố vào ngày 17 tháng 8 chuyển sang một hệ thống quyền hạn.

Tất nhiên, việc tận dụng lỗ hổng Máy ảo đối với Rollup ở giai đoạn 0 hoặc giai đoạn 1 có thể không ảnh hưởng lớn, vì Ủy ban An ninh có thể can thiệp bất cứ lúc nào để sửa chữa kết quả bị nghi ngờ. Đây là quan điểm mà OP Labs đã đề xuất trước đây. Thực tế, OP Labs đã chia sẻ khung kiểm toán của mình trên Optimism Forum, đưa ra tổng quan về tiêu chuẩn khi nào cần tiến hành kiểm toán bên ngoài.

(OP Labs Framework Kiểm toán | Nguồn: Diễn đàn Optimism)

Trong khung việc này, tình huống gần đây thuộc về phần tư thứ tư: 'Chứng minh sự cố trong giai đoạn hỗ trợ'. Mặc dù những tình huống này liên quan đến an ninh của chuỗi khối, nhưng không ảnh hưởng trực tiếp đến nguồn vốn của người dùng, do đó không được bao gồm trong phạm vi kiểm toán. Điều này có nghĩa là ngay cả khi lợi dụng lỗ hổng, Ủy ban an ninh vẫn có thể sửa chữa kết quả.

Tuy nhiên, một khi đã xác định được lỗ hổng, cần phải giải quyết những vấn đề đó. Optimism đã sửa các vấn đề này trong phiên bản nâng cấp mạng Granite của mình, cho phép OP Mainnet phục hồi về giai đoạn 1.

Mặt khác, lỗ hổng trong hệ thống có thể là chết người trong giai đoạn 2 của Rollup. Trong giai đoạn 2, ủy ban an ninh chỉ có thể can thiệp khi có chứng cứ trên chuỗi (on-chain) về lỗ hổng. Vì rất khó để chứng minh "kết quả tranh chấp sai lầm do lỗi hệ thống" trên chuỗi (on-chain), nên nếu có lỗ hổng trong giai đoạn 2 của Rollup, nguồn vốn của người dùng có thể gặp rủi ro.

3.7 Giải pháp #3: Chứng minh nhiều lần

Để ngăn chặn các vấn đề như vậy, việc kiểm toán toàn diện trước khi triển khai mã vào sản xuất là rất quan trọng. Tuy nhiên, Máy ảobằng chứng gian lận và chương trình là các hệ thống phần mềm phức tạp, và độ phức tạp càng cao thì khả năng xuất hiện lỗ hổng càng lớn. Do đó, ngay cả sau khi kiểm toán nghiêm ngặt, vẫn có thể xuất hiện lỗ hổng. Chúng ta cần tìm hiểu các chiến lược bổ sung ngoài việc kiểm toán.

Một phương pháp là sử dụng nhiều hệ thống chứng minh trong cùng một hệ thống. Trong quá trình tranh chấp, hệ thống không chỉ sử dụng một hệ thống duy nhất để tạo ra bằng chứng gian lận, mà có thể sử dụng đồng thời các Máy ảo và chương trình khác nhau để tạo ra nhiều bằng chứng gian lận, sau đó so sánh kết quả. Điều này sẽ tạo ra một hệ thống an toàn ngay cả khi xảy ra lỗ hổng.

Ví dụ, hãy tưởng tượng một hệ thống chứng thực đa lớp sử dụng cùng lúc Cannon của Optimism và bằng chứng lỗi ZK asterisc (sử dụng Máy ảo Risc-V). Trong trường hợp tranh chấp, các tình huống sau sẽ xảy ra:

Nếu phát hiện đầu ra sai lệch, người nghi ngờ sẽ tạo ra một nghi ngờ và khởi xướng phương pháp chia đôi.
Một khi tìm thấy Khối không đồng nhất thông qua phương pháp chia đôi, hai trò chơi con sẽ xảy ra cùng lúc:

Subgame của Cannon sử dụng phương pháp OPFP truyền thống. Sử dụng asterisc để tạo ra subgame chứng minh lỗi ZK.

Sau hai trò chơi, sẽ xác minh hai loại bằng chứng gian lận khác nhau.

Nếu cả hai chứng minh đều được xác minh, người nghi ngờ sẽ chiến thắng; Nếu cả hai chứng minh đều không được xác minh, người nghi ngờ sẽ thất bại. Tuy nhiên, nếu một cái được xác minh và cái kia không được, điều này cho thấy rằng có một lỗi không mong muốn xuất hiện trong quá trình tạo ra chứng minh của Máy ảo hoặc chương trình nào đó.

Trong trường hợp này, các tổ chức như Hội đồng An toàn sẽ tham gia để điều chỉnh kết quả tranh chấp. Điều này đảm bảo hệ thống có thể duy trì không có lỗi, đồng thời không vi phạm điều kiện 'Hội đồng An toàn chỉ có thể can thiệp trong trường hợp có thể chứng minh được lỗ hổng trên chuỗi'.

Đây là một trong những nỗ lực liên tục để đạt được giai đoạn 2 của Optimism. Để hỗ trợ điều này, trò chơi tranh chấp của OPFP liên quan đến việc tạo ra hệ thống modul hóa, cho phép triển khai nhiều hệ thống chứng minh gian lận và xác định giao diện tối thiểu để hỗ trợ điều này.

4. Cải tiến khả thi

Trong các chương trước, chúng ta đã thảo luận về thiết kế của giao thức Optimistic Rollup và các lỗ hổng có thể xảy ra trong quá trình kiểm chứng và xác minh bằng chứng gian lận. Phần này sẽ thảo luận về các vấn đề và giải pháp của mỗi giao thức, cũng như triển vọng tương lai của hệ thống bằng chứng gian lận và Optimistic Rollup.

4.1 Không gian cải tiến của các giao thức

1) Arbitrum BoLD

BoLD có giao thức kinh tế vững chắc vì nó giới hạn độ trễ giao thức tối đa trong một tuần và đảm bảo hiệu quả chống lại cuộc tấn công Sybil trước khi số tiền của kẻ tấn công vượt qua 6,5 lần số tiền của người phòng thủ. Tuy nhiên, BoLD đang gặp hai vấn đề đáng kể:

Tỷ lệ tài nguyên tăng 6,5 lần quá nhỏ so với lợi thế của người phòng thủ.
Tiền đặt cọc gốc là 3.600 ETH, số tiền này quá lớn.

Vấn đề đầu tiên có thể được giải quyết thông qua công nghệ ZK. BoLD chia sẻ sự hoài nghi thành nhiều cấp độ để giảm tài nguyên cần thiết cho việc tính toán cam kết lịch sử. Bằng cách sử dụng ZK, điều này có thể giảm xuống chỉ còn một cấp độ duy nhất.

Khái niệm này tương tự với đề xuất BoLD++ của Gabriel của Cartesi. Khi câu hỏi được chia thành nhiều cấp độ, việc tăng tỷ lệ tài nguyên sẽ dẫn đến mức tiền đặt cược ở cấp độ cao nhất tăng lên theo cấp số mũ. Tuy nhiên, khi sử dụng một cấp độ duy nhất, có thể dễ dàng tăng tỷ lệ tài nguyên, giúp giao thức chống lại cuộc tấn công Sybil hơn.

Vấn đề thứ hai, đó là việc đặt cọc 3,600 ETH, là một vấn đề khó khăn hơn để giải quyết. Quy mô đặt cọc của BoLD không chỉ để chống lại cuộc tấn công Sybil, mà còn để đe dọa cuộc tấn công Trễ. Quy mô đặt cọc là một hàm của TVL (Tổng giá trị khóa) và ngay cả khi sử dụng ZK, nó cũng không thể được giảm đi đáng kể. Để giải quyết vấn đề này, BoLD đang triển khai một cơ chế đặt cọc theo mô hình mỏ đồng thời, cho phép nhiều người tham gia chịu trách nhiệm chung về việc đặt cọc.

2) Cartesi Dave

Dave đã hiệu quả đối phó với cuộc tấn công Sybil thông qua cấu trúc giải đấu của mình, nhưng như đã được đề cập trước đó, nó dễ dàng bị tấn công Trễ. Thời gian Trễ tối đa là một hàm của số lượng tuyên bố xấu tính NA và số lượng cấp độ thế chấp L, với công thức tính toán là: Td = 7 x [log2(1 + NA)]L(天数)

Nếu NA = 7 và L = 3, giao thức có thể đối mặt với Trễ kéo dài tới bốn tháng, gây ra sự bất tiện và thiệt hại đáng kể cho người dùng vì việc rút tiền sẽ bị Trễ.

ZK có thể giúp giảm bớt vấn đề này. Bằng cách cố định cấp độ L thành 1 (như dòng BoLD++), thời gian trễ tối đa có thể giảm xuống: Td = 7 x log2(1 + NA)(ngày)

Theo báo cáo, Cartesi đang sử dụng công nghệ ZK của RISC Zero để cải thiện này. Tuy nhiên, vẫn còn lo ngại về việc liệu cải tiến này có đủ để ngăn chặn tấn công Trễ hoàn toàn hay không. Nếu NA = 7, giao thức có thể vẫn đối mặt với Trễ kéo dài thêm hai tuần, trong khi chi phí của kẻ tấn công chỉ là tiền đặt cọc 7 ETH, cộng với phí Gas và chi phí cam kết lịch sử ngoại tuyến. Đối với chuỗi có giá trị Vị thế bị khóa cao, hình phạt này có thể không đủ để đe dọa tấn công Trễ.

（Dave: Cơ chế đặt câu hỏi con phong cách BoLD | Nguồn: L2Beat Medium）

Có một đề xuất để Dave sử dụng cơ chế đặt câu hỏi theo phong cách BoLD, trong đó 8 người tham gia được so sánh trong mỗi vòng, thay vì thi đấu 1 đấu 1, giống như giải đấu truyền thống. Trong trường hợp này, công thức tính thời gian Trễ là:

Td = 7 x log8(1 + NA)(ngày)

Trong cấu trúc này, kẻ tấn công cần cung cấp ít nhất 64 ETH Ký quỹ để chống lại Trễ hơn hai tuần, tổng yêu cầu Ký quỹ là 64 ETH, và phải chịu một lượng lớn on-chain và ngoại chuỗi chi phí.

Tuy nhiên, điều không tốt của phương pháp này là làm suy yếu lợi thế của người phòng thủ trong trường hợp bị tấn công Sybil. Mặc dù BoLD cung cấp một cấu trúc cho người phòng thủ có lợi thế gấp N lần so với kẻ tấn công, nhưng Dave đã tạo ra một lợi thế mũi nhọn của người phòng thủ vượt xa kẻ tấn công theo cấp số nhân.

Tóm lại, Dave có thể hạn chế hiệu quả vector của các cuộc tấn công Trễ bằng cách sử dụng bằng chứng gian lận ZK. Mặc dù việc áp dụng cấu trúc tương tự như BoLD có thể tăng cường khả năng chống lại cuộc tấn công Trễ, nhưng điều này có thể dẫn đến lợi thế của người phòng thủ khi đối mặt với cuộc tấn công Sybil.

3) Bằng chứng lỗi lạc quan (OPFP)

Nhược điểm của OPFP là dễ bị tấn công Sybil, bởi vì chi phí cho kẻ tấn công và người phòng thủ là bằng nhau. OP Labs đã đưa ra giải pháp cho vấn đề này trong Trò chơi tranh chấp V2.

Khác với OPFP ban đầu, phiên bản sau yêu cầu người tham gia đặt Ký quỹ mỗi lần khi chia đôi, trong khi trò chơi tranh chấp V2 chỉ yêu cầu người tham gia đặt Ký quỹ khi bắt đầu chia đôi. Ngoài ra, trò chơi tranh chấp V2 giới thiệu phương pháp chia đôi, cho phép người tham gia đồng thời gửi nhiều yêu cầu tại điểm nhánh, từ đó giảm số lần tương tác trong hầu hết các trường hợp.

（Tuyên bố nhánh trong Trò chơi tranh chấp V2 | Nguồn: Optimism Specs GitHub）

Trong OPFP trước đó, các vector tấn công Sybil bao gồm:

Tạo ra một lượng lớn nghi ngờ để tiêu hao Ký quỹ và phí Gas của người bảo vệ.
Tiếp tục đệ trình đầu ra giả mạo để buộc người phòng vệ phải đáp ứng và tiêu tốn tài nguyên của họ.

Việc giới thiệu khai báo chi nhánh đã giải quyết hai vấn đề về vector này. Đầu tiên, người tham gia trung thực không cần phải đóng thêm Ký quỹ trong quá trình chia đôi, trong khi kẻ thù nghi ngờ phải đặt cược cho mỗi nghi ngờ mới mà họ tạo ra. Nếu số tiền cược được đặt đúng, việc tấn công bằng cách tạo ra nhiều nghi ngờ trở nên không bền vững.

Thứ hai, trong Trò chơi tranh chấp V2, số tiền Ký quỹ cấp cao hơn có giá trị lớn hơn, do đó chi phí liên tục đệ trình đầu ra giả mạo đối với kẻ tấn công cao hơn so với kẻ phòng thủ.

Do đó, OPFP có thể hiệu quả đối phó với cuộc tấn công Sybil thông qua tuyên bố nhánh được giới thiệu trong trò chơi tranh chấp V2.

4) Kroma ZK Chống lỗi (Kroma ZKFP)

Kroma ZKFP đối mặt với hai thách thức lớn: sự dễ bị tấn công Sybil và hệ thống chứng minh không hoàn thiện. Để tiến hành đến giai đoạn 1, Kroma ZKFP cần giải quyết hai vấn đề sau:

Điểm bắt đầu của phương pháp chia đôi dựa trên kết quả đầu ra cuối cùng được nộp, không phải là kết quả đầu ra cuối cùng được xác định.
Người xác thực chưa xác minh xem liệu nghi vấn có dựa trên dữ liệu hàng loạt chính xác hay không.

Kế hoạch Kroma chuyển từ Halo2 zkEVM của Scroll sang SP1 zkVM ngắn gọn để giải quyết hai vấn đề này và tiến hành giai đoạn 1.

Kroma dự định sẽ điều chỉnh quy trình tranh chấp của mình để tương thích với giao diện trò chơi tranh cãi của Optimism. Sự điều chỉnh này được mô tả chi tiết trong tiêu chuẩn của Kroma, nó sẽ cho phép dịch chuyển điểm bắt đầu của phân mảnh đến đầu ra cuối cùng được xác định vào một tuần trước, từ đó giải quyết vấn đề đầu tiên.

Đối với câu hỏi thứ hai, Kroma sẽ sử dụng suy luận không tin cậy dựa trên ZK. Cách hoạt động cụ thể như sau:

(Sử dụng rút ra không tin cậy của ZK | Nguồn: Lightscale Notion)

Hãy tưởng tượng rằng chúng ta muốn chứng minh rằng một Khối T cụ thể trên L2 được thực hiện đúng. Trước khi tạo ra chứng minh ZK, chúng ta phải xác minh xem dữ liệu giao dịch của Khối T có được xây dựng đúng dựa trên dữ liệu hàng loạt L1 hay không.

Ở đây, Kroma dự định xác minh dữ liệu hàng loạt đã được trích xuất đúng từ L1 bằng ZK chứng thực. Nếu dữ liệu chỉ được lấy từ RPC đáng tin cậy bên ngoài chương trình ZK, thì không thể xác nhận liệu dữ liệu hàng loạt đã bị thay đổi hay không. Có thể xác minh tính đúng đắn của dữ liệu hàng loạt đã được trích xuất bằng chứng ZK về tính liên kết của Khối, từ Khối Hàm băm (nguồn gốc L1 của Khối T L2) đến Khối C (Khối L1 tạo ra khi tạo ra sự tranh cãi). Nếu người tranh cãi xây dựng Khối T L2 dựa trên dữ liệu hàng loạt sai, Hàm băm của Khối L1 được trích xuất bởi người tranh cãi sẽ khác với Hàm băm của Khối L1 thực sự chứa dữ liệu hàng loạt (bao gồm T1), và nó cũng không được liên kết với Khối C. Do đó, chỉ cần không có xung đột Hàm băm, việc xác minh tính liên kết của Khối L1 bằng ZK có thể chứng minh người tranh cãi đã xây dựng Khối T L2 đúng từ dữ liệu hàng loạt.

Kế hoạch Kroma sử dụng ZK để xác minh tính chính xác của dữ liệu đại trà, điều này có thể kiểm tra sự kết nối của Khối L1 tới Khối C thông qua Hàm băm. Nếu người nghi ngờ xây dựng Khối L2 T dựa trên dữ liệu đại trà sai lệch, Hàm băm của Khối L1 được tham chiếu sẽ khác với Khối L1 chứa dữ liệu đại trà chính xác, và không kết nối với Khối C. Do không có xung đột Hàm băm, quá trình nghi ngờ có thể được xác minh với dữ liệu đại trà chính xác bằng phương pháp này.

Nhờ những cải tiến này, Kroma ZKFP sẽ có thể nhập vào giai đoạn 1. Tuy nhiên, để đạt được giai đoạn 2, Kroma cần các giải pháp bổ sung để ngăn chặn cuộc tấn công Sybil, bao gồm việc thay đổi giao thức tranh chấp thành All-vs-All và thiết kế lại cơ chế Ký quỹ.

4.2. Tóm tắt

5. Tương lai của bằng chứng gian lận

5.1. Pha 2 Rollup - Quỹ của bạn an toàn

Như đã nói ở trên, Rollups lạc quan đang phát triển vào giai đoạn 2. Arbitrum đang cố gắng thực hiện giai đoạn 2 dựa trên BoLD. Kế hoạch triển khai BoLD đã được đăng trên Diễn đàn quản trị và đã nhận được rất nhiều sự ủng hộ, hiện đang triển khai trên mạng thử nghiệm. Nếu không có vấn đề an ninh quan trọng được phát hiện, Arbitrum có thể thực hiện giai đoạn 2 trước cuối năm nay thông qua BoLD.

Optimism cũng đang nỗ lực để đạt giai đoạn 2. Để đưa Mạng chính OP đến Giai đoạn 2, cần hoàn thành Trò chơi tranh chấp V2 và cần có nhiều cơ chế chứng minh hỗ trợ chứng minh đa dạng. Mặc dù tiêu chuẩn vẫn đang được hoàn thiện, nhưng Trò chơi tranh chấp V2 đã hiệu quả giải quyết điểm yếu hiện tại của OPFP, cung cấp sự bảo vệ mạnh mẽ để chống lại cuộc tấn công Sybil, khiến nó gần hơn với Giai đoạn 2. Ngoài ra, nhiều nhóm khác nhau, bao gồm OP Labs, Succinct, Kroma và Kakarot, đều tích cực phát triển chứng minh đa dạng, đầu tư một lượng lớn tài nguyên nghiên cứu và phát triển để tạo ra cách chứng minh OP Stack đa dạng. Do đó, trừ khi có vấn đề lớn xuất hiện, dự kiến Optimism cũng sẽ tiến vào Giai đoạn 2 vào đầu năm sau.

Việc hai Rollup chuyển sang giai đoạn 2 có thể tạo ra tác động lớn đối với hệ sinh thái Rollup. Arbitrum và Optimism mỗi cái đều có khung Rollup riêng của mình, tương ứng là Arbitrum Orbit và OP Stack. Việc chuyển sang giai đoạn 2 của chúng đồng nghĩa với việc tất cả các Rollup sử dụng khung này cũng có thể chuyển sang giai đoạn 2.

Do đó, từ cuối năm nay đến năm sau, các Rollup chính với cơ sở người dùng lớn như Arbitrum, OP Mạng chính và Base dự kiến sẽ chuyển sang giai đoạn 2, kế thừa tính bảo mật toàn diện của Ethereum. Điều này có thể làm dịu bớt chỉ trích như 'Rollup chỉ là đa chữ ký' hoặc 'Rollup có thể tiếp cận tài sản của bạn bất cứ lúc nào'.

5.2. ZK bằng chứng gian lận是未来

Đặc biệt, hiện nay đã có những giao thức được thượng luận tới có thể hưởng lợi từ việc triển khai ZK bằng chứng gian lận. Ví dụ, áp dụng ZK vào Arbitrum BoLD có thể nâng cao tỷ lệ nguồn lực, góp phần tăng khả năng chống lật đổi Sybil, trong khi Cartesi Dave có thể làm giảm khả năng bị tấn công Trễ. OPFP cũng đang phát triển ZK để hỗ trợ hệ thống chứng chỉ đầu tiên, điều này có thể giảm áp lực Ký quỹ và tăng cải thiện an ninh giao thức.

Đáng chú ý là, ZK bằng chứng gian lận không chỉ đồng nghĩa với việc giảm thiểu sự tương tác giữa Người xác thực. Ít tương tác hơn có nghĩa là tài nguyên cần thiết cho Người xác thực giảm đáng kể, từ đó Thả Ký quỹ số tiền, giúp nhiều người tham gia giao thức hơn. Ngoài ra, điều này cũng giảm thiểu mức độ Trễ có thể xảy ra, nâng cao tính an toàn toàn bộ giao thức.

ZK bằng chứng gian lận đóng vai trò quan trọng trong việc đảm bảo an toàn và tính phi tập trung của Optimistic Rollup thông qua phương thức này.

5.3. ZK Rollup 表现如何？bằng chứng gian lận会变弱吗？

Lúc này, một số độc giả có thể hỏi: Nếu bằng chứng gian lận và cơ chế nghi ngờ là phức tạp như vậy, liệu ZK Rollups có phải là lựa chọn tốt hơn không? Đến một mức độ nào đó, điều này là đúng. Trong ZK Rollups, đạt được giai đoạn 2 không cần phải xem xét những yếu tố kinh tế phức tạp, nguy cơ mất tiền của người dùng trong sự kiện kiểm tra L1 không phải lo lắng, người dùng có thể rút tiền trong vài giờ.

Optimistic Rollups chuyển tiếp sang ZK Rollups có thể nhanh hơn dự kiến. Điều này là do nhược điểm chính của ZK Rollups - chi phí và thời gian tạo chứng minh rất cao - đang nhanh chóng cải thiện. Gần đây, Succinct Labs đã ra mắt OP Succinct, một phiên bản ZK dựa trên OP Stack, cung cấp một khung ZK Rollups dễ dàng khởi động.

OP Succinct 简介 | 来源：Succinct 博客

Tuy nhiên, vẫn còn một số yếu tố cần xem xét. Đầu tiên là chi phí. Trong OP Succinct, chi phí để tạo ra một Khối chứng thực là khoảng từ $0.005 đến $0.01, và ước tính chi phí hàng tháng để chạy trình chứng thực nằm trong khoảng từ $6,480 đến $12,960. Nếu lưu lượng giao dịch trên chuỗi cao (TPS), những chi phí này có thể tăng lên thêm.

（成本证明网络Điểm chuẩn | 来源：Succinct 博客）

Ví dụ, trên mạng lưới cơ bản OP Succinct, chi phí trung bình để tạo ra một khối là khoảng $0.62. Tính theo số liệu này, chi phí hàng tháng sẽ đạt $803,520. Đây là một chi phí bổ sung mà Optimistic Rollups không có, ngay cả khi chi phí ZK được giảm bớt, chi phí vận hành của ZK Rollups vẫn luôn cao hơn Optimistic Rollups.

Một yếu tố thứ hai cần xem xét là ảnh hưởng đến Phi tập trung. Trong ZK Rollups, Người xác thực cần chạy trình chứng minh, điều này khó khăn và tốn kém hơn so với việc chạy chương trình bằng chứng gian lận trong Optimistic Rollups. Ngoài ra, do thời gian tạo chứng minh trong hệ thống ZK chậm, người dùng không thể xác minh giao dịch trong thời gian thực. Mặc dù tiêu chuẩn phần cứng cao hơn có thể cải thiện tốc độ tạo chứng minh để phù hợp với tốc độ thực hiện giao dịch, nhưng điều này đồng nghĩa với việc chạy trình chứng minh yêu cầu môi trường tính toán cao. Lý tưởng nhất, bất kỳ ai cũng nên có thể chạy một Nút để đảm bảo an ninh của chuỗi, nhưng ZK hiện tại chưa đạt được mức đó.

Cuối cùng, ZK Rollups dựa trên toán học và mật mã rất phức tạp, phức tạp hơn so với phạm vi của bằng chứng gian lận và sự đặt câu hỏi về giao thức. Do đó, trước khi có thể sử dụng an toàn trong sản xuất, hệ thống ZK cần được kiểm tra rộng rãi.

Arbitrum đang theo đuổi một phương pháp kết hợp giữa giao thức ZK và Optimistic như một mục tiêu cuối cùng của nó. Giao thức này hoạt động chủ yếu như Optimistic Rollup, chỉ tạo ra chứng minh ZK khi cần rút tiền nhanh. Điều này rất hữu ích trong các tình huống cần cân bằng lại vốn nhanh chóng giữa các chuỗi (ví dụ như sàn giao dịch hoặc cầu nối Cross-chain), cũng như giúp thúc đẩy tương tác giữa các chuỗi.

Nhìn chung, phương pháp Optimistic Rollup hiện tại dường như hiệu quả, đồng thời sử dụng ZK như một giải pháp kết hợp. Tuy nhiên, với sự liên tục cải thiện về chi phí và tốc độ của việc tạo ra chứng minh ZK, trong tương lai, có thể sẽ có nhiều hơn những sự xem xét nghiêm túc về việc chuyển đổi sang ZK.

5.4. bằng chứng gian lận chỉ áp dụng cho Rollup?

Chúng tôi đã nghiên cứu về Optimistic Rollups của Ethereum và cơ chế bằng chứng gian lận của nó. Vậy, cơ chế bằng chứng gian lận này còn được áp dụng trong những lĩnh vực ứng dụng nào khác nữa không?

再thế chấp giao thức Bằng chứng gian lận có thể được tích cực sử dụng trong các dịch vụ thế chấp, giao thức. Chúng ta lấy ví dụ về Eigenlayer, đây là một dịch vụ thế chấp đại diện trên ETH.

Eigenlayer là một dịch vụ cho phép thế chấp ETH và cho thuê ETH một cách an toàn. Trong Eigenlayer, các nhà điều hành có thể gửi ETH hoặc LST của người dùng theo hợp đồng ủy quyền trong Eigenlayer và tham gia xác thực bằng cách chọn nhiều dịch vụ xác thực tích cực (AVS). Với Eigenlayer, giao thức có thể dễ dàng xây dựng AVS và giảm thiểu chi phí khởi đầu của Người xác thực.

Như bất kỳ chuỗi khối nào khác, AVS sẽ thưởng cho các nhà vận hành đã xác minh thành công và buộc họ phải bị phạt khi họ thực hiện hành vi ác ý. Đó chính là nơi mà bằng chứng gian lận có thể được sử dụng trong quá trình phạt.

Ví dụ phạt của AVS | Nguồn: Eigenlayer GitHub

Ví dụ với cầu AVS. Điều kiện tiên quyết của cầu AVS là phải chuyển tiền của người dùng đúng cách sang chuỗi mục tiêu, bất kỳ nhà điều hành gian lận giao dịch nào cũng nên bị phạt. Nếu có sự gian lận như vậy, người nghi ngờ phát hiện hành vi không đúng có thể tạo một sự tranh chấp có bằng chứng gian lận trong hợp đồng giải quyết tranh chấp, tuyên bố rằng nhà điều hành đã thực hiện không đúng trong quá trình cầu. Nếu bằng chứng gian lận được coi là hợp lệ, AVS có thể gọi hợp đồng phạt trong Eigenlayer, tạm ngừng bất kỳ phần thưởng nào của nhà điều hành đó.

Mặc dù tính năng phạt này chưa được triển khai trong Eigenlayer, nhưng gần đây họ đã thông báo về mô hình bảo mật chia sẻ, kế hoạch bao gồm tính năng phạt trong phiên bản tiếp theo. Điều này sẽ cho phép sử dụng bằng chứng gian lận để phạt.

Lớp khả dụng dữ liệu** **Bằng chứng gian lận cũng có thể được sử dụng trong lớp tính sẵn sàng dữ liệu (DA). Một ví dụ đại diện là bằng chứng gian lận được đề xuất và triển khai bởi Celestia. Celestia có một công nghệ cho phép nút sáng xác minh xem dữ liệu đã được lưu trữ đúng cách hay không dựa trên việc lấy mẫu sẵn sàng dữ liệu. Hãy cùng tìm hiểu kỹ về khái niệm này.

Khách hàng ánh sáng nên có thể xác minh một khối đã được hơn 67% người xác thực chấp nhận mà không cần tải xuống tất cả dữ liệu chuỗi khối. Tuy nhiên, việc xác minh tất cả các chữ ký của người xác thực cho mỗi khối là rất khó và với sự gia tăng của số lượng người xác thực, điều này trở nên gần như bất khả thi.

Về vấn đề này, Celestia đã đưa ra một khái niệm thú vị. Ở Celestia, mặc dù phần lớn Người xác thực là độc hại, nhưng nó đề xuất một phương pháp cho phép một Nút đầy đủ trung thực duy nhất thông báo cho khách hàng ánh sáng để từ chối Khối bị lỗi. Sự trung thực duy nhất này toàn bộ Nút có thể đảm bảo "sự trung thực" của nó bằng chứng gian lận.

Trong Celestia, có hai loại bằng chứng gian lận:

Bằng Chứng Gian Lận cho quá trình chuyển đổi nhà nước

Đầu tiên, nguyên tắc hoạt động của bằng chứng gian lận dữ liệu như sau: Celestia cho phép nút sáng xác minh xem Người xác thực có thông tin chính xác hay không mà không cần tải trực tiếp dữ liệu trong khối. Để làm được điều này, Celestia sử dụng một công nghệ gọi là mẫu kiểm tra tính khả dụng dữ liệu (Data Availability Sampling, DAS).

Mẫu sẵn có của dữ liệu Celestia | Nguồn: Tài liệu Celestia

Celestia 的Người xác thực将交易数据结构化为一个 k x k 的矩阵，然后使用称为 2D Reed-Solomon 编码的技术将其扩展为 2k x 2k 的矩阵。他们随后计算每行和每列的总共 4k 个Gốc Merkle，并将进一步Hàm băm这些Gốc Merkle的结果包含在Khối头中并传播。

Chỉ với thông tin Gốc Merkle trong tiêu đề Khối, nút sáng có thể xác minh xem Người xác thực của Celestia có giữ chính xác dữ liệu hay không. Nút sáng yêu cầu dữ liệu từ điểm ngẫu nhiên trong ma trận 2k x 2k và lấy Gốc Merkle tương ứng từ hàng và cột tương ứng từ Người xác thực. Nếu những dữ liệu này có thể được xác minh với giá trị trong tiêu đề Khối, thì có thể tin tưởng rằng Những người xác thực này đang giữ chính xác dữ liệu.

Tuy nhiên, một cân nhắc quan trọng được đặt ra: điều gì sẽ xảy ra nếu Người xác thực thực hiện mã hóa Reed-Solomon một cách ác ý? Celestia giải quyết vấn đề này bằng cách thực hiện một cơ chế gọi là "mã hóa xấu bằng chứng gian lận". Nếu Nút đầy đủ của Celestia thấy rằng mã hóa không chính xác trong quá trình khôi phục Khối, nó sẽ tạo ra một bằng chứng gian lận chứa chiều cao khối, phần được mã hóa không chính xác và bằng chứng lỗi, và lan truyền nó ra ánh sáng Nút. Light Nút xác minh bằng chứng để xác nhận rằng dữ liệu thực sự được mã hóa không chính xác, do đó ngăn chặn việc sử dụng dữ liệu sai.

Ngoài ra, Celestia còn đề xuất cơ chế chứng minh gian lận chuyển trạng thái.

Kiến trúc Celestia Khối | Nguồn: Contribution DAO Blog

Cấu trúc Khối của Celestia bao gồm dữ liệu theo dõi giao dịch tại các khoảng thời gian khác nhau. Điều này cho phép Toàn bộ nút dễ dàng xây dựng bằng chứng gian lận, nút sáng có thể phát hiện trạng thái chuyển đổi không chính xác mà không cần thực hiện toàn bộ Khối. Tuy nhiên, do vấn đề phức tạp, cơ chế này vẫn chưa được triển khai trên Mạng chính của Celestia.

总之，数据可用性层中的bằng chứng gian lận可以在不依赖Nhận thức chung的情况下过滤不正确的数据和状态转换。

Học máy Trong năm 2024, trí tuệ nhân tạo và blockchain đã trở thành chủ đề nóng, với nhiều nghiên cứu và phát triển trong lĩnh vực này. Một trong những khía cạnh đáng chú ý nhất là sự kết hợp giữa blockchain và học máy.

Một số lý do chính để áp dụng học máy vào blockchain là như sau:

Độ tin cậy dữ liệu: Khối Chain quản lý dữ liệu theo cách Phi tập trung, tất cả các giao dịch được ghi lại một cách công khai và minh bạch. Nếu mô hình học máy học từ dữ liệu trên Khối Chain, nguồn dữ liệu sẽ đáng tin cậy và giảm thiểu khả năng gian lận.
Sự minh bạch và khả năng xác minh của mô hình: Khi mô hình học máy được thực thi trên Khốion-chain, các cập nhật và kết quả của mô hình được ghi lại trên on-chain, làm cho nó có thể xác minh. Điều này ngăn chặn việc thao tác hoặc thiên vị kết quả có thể xảy ra trong môi trường tập trung.

Yếu tố quan trọng ở đây là xác minh xem mô hình học máy đã được đào tạo đúng cách hay không. Tuy nhiên, tính toán học máy rất mật độ, điều này làm cho việc thực hiện đầy đủ các tính toán này trên môi trường Khối-chain gần như là không thể. Do đó, các khung như opML và zkML đã ra đời để xác minh hiệu quả việc đào tạo mô hình học máy trong môi trường Khối-chain. opML sử dụng phương pháp lạc quan để đào tạo mô hình và ghi lại kết quả trên Khối-chain, và sửa chữa lỗi thông qua cơ chế nghi ngờ.

Hãy xem phương pháp được đề xuất bởi ORA một cách cẩn thận hơn, ORA là một dự án cung cấp hạ tầng trí tuệ nhân tạo trên blockchain. Quá trình thách thức của opML rất giống với quá trình thách thức của rollup, bao gồm ba thành phần chính sau:

bằng chứng gian lậnMáy ảo（Fraud Proof VM）：Các Máy ảo này thực hiện suy luận học máy, chức năng của chúng tương tự như WAVM của Arbitrum hoặc Cannon của Optimism.
opML Hợp đồng thông minh：Các hợp đồng này xác minh bằng chứng gian lận, tương tự như hợp đồng MIPS.sol của Optimism.
Trò chơi xác thực: Người xác thực đưa ra thử thách và tương tác với máy chủ bằng phương pháp phân chia đôi để nhận ra các bước sai lầm trong Máy ảo, sau đó tạo ra bằng chứng gian lận cho bước đó và gửi nó đến hợp đồng OPML.

Trò chơi xác minh trên ORA opML | Nguồn: ORA tài liệu

Thông qua cơ chế bằng chứng gian lận này, OPML sử dụng tính an toàn và đáng tin cậy của blockchain, đồng thời cung cấp môi trường hiệu quả về chi phí cho việc huấn luyện và xác minh mô hình học máy.

6. Kết luận

Optimistic Rollup đang nỗ lực rất nhiều để cải thiện bằng chứng gian lận và đặt câu hỏi về giao thức để kế thừa nhiều bảo mật hơn của Ethereum và tạo ra một chuỗi với ít sự tin tưởng hơn. Arbitrum dự kiến sẽ đạt đến Giai đoạn 2 thông qua BoLD vào cuối năm nay và Optimism cũng đang hướng tới Giai đoạn 2, dựa trên trò chơi gây tranh cãi V2 và các cơ chế đa bằng chứng. Đến năm tới, người dùng Optimistic Rollup sẽ có thể tương tác với mạng với độ bảo mật cao hơn mà không phải lo lắng rằng "Rollup có thể lấy tiền của họ". Ngoài ra, Vitalik đề cập trong blog của mình rằng số lượng bản tổng hợp trong Giai đoạn 1 trở lên dự kiến cũng sẽ tăng lên.

Tuy nhiên, mỗi giao thức vẫn còn không gian để cải thiện và nhiều khía cạnh có thể được tăng cường bằng bằng chứng gian lận ZK. Kroma đã tiến xa hơn với giao thức của mình và các giao thức khác như Arbitrum, Optimism và Cartesi cũng có thể sử dụng bằng chứng gian lận ZK để duy trì một cách an toàn, phi tập trung hơn.

Trong lĩnh vực bằng chứng gian lận, không chỉ có Rollup mà còn có rất nhiều giao thức khác đang được đầu tư một lượng lớn tài nguyên nghiên cứu phát triển. Dưới điều kiện 'chỉ cần một bên tham gia trung thực', bằng chứng gian lận kết hợp với ZK có thể giúp xây dựng một cấu trúc Blockchain tối thiểu hóa niềm tin, ảnh hưởng của nó sẽ cuối cùng trở thành hiện thực mà chúng ta có thể cảm nhận được.

7. Tài liệu tham khảo

(https://l2beat.com/scaling/summary)[L2Beat]

bằng chứng gian lận战争 | Luca Donnoh at L2Beat

Arbitrum 文件

Optimism 文件

Optimism 规格

Trò chơi không có trọng tài | Cartesi

Kroma 规格

BoLD: Giải quyết tranh chấp nhanh chóng và chi phí thấp

BoLD 的经济学

Tại sao chu kỳ thách thức của Rollup lạc quan là 7 ngày? | Kelvin Fichter tại OP Labs

bằng chứng gian lận已崩溃 | Gabriel Coutinho de Paula at Cartesi

乐观时间旅行 | Yoav Weiss

Giới thiệu về thách thức thành công đầu tiên trên Mạng chính Kroma

解读基线Phi tập trung的进展 | OP Labs

攻击对基于bằng chứng gian lận的 Layer2 giao thức的不可归因的审查

OP Labs Audit Framework

无信任的推导 | Kroma

介绍 OP Succinct：在 OP Stack 上的完整bằng chứng hợp lệ | Succinct

Tuyên bố:

Bài viết này được sao chép từ [research.2077], tất cả quyền tác giả thuộc về người viết gốc [sm-stack và BTC Penguin]. Nếu có bất kỳ ý kiến nào về việc sao chép này, vui lòng liên hệ với đội Gate Learn, họ sẽ xử lý kịp thời.
声明：Quan điểm và ý kiến được thể hiện trong bài viết chỉ đại diện cho quan điểm cá nhân của tác giả, không cấu thành bất kỳ lời khuyên đầu tư nào.
Gate Learn đội sẽ dịch bài viết sang các ngôn ngữ khác. Trừ khi có hướng dẫn khác, cấm sao chép, phân phối hoặc sao chép bài dịch.